ROSE Compiler Framework/How to debug a translator
It is rare that your translator will just work after your finish up coding. Using gdb to debug your code is indispensable to make sure your code works as expected. This page shows examples of how to debug your translator.
Preparations[edit | edit source]
First and foremost, make sure your ROSE installation and your translator was built with -g and without GCC optimizations turned on. This will ensure all debug information will be best preserved.
To configure ROSE installation with debugging options, you can add the following options to your normal configuration.
../rose/configure—with-CXX_DEBUG=-g --with-C_OPTIMIZE=-O0—with-CXX_OPTIMIZE=-O0 ...
If you already built ROSE but forgot what options you used, you can go to your buildtree of ROSE to double check if debugging options are used:
cd buildDebug/ -bash-4.2$ head config.log $ ../sourcetree/configure --with-java=/path/to/java/jdk/1.8.0_131 --with-boost=/path/to/boost/1_60_0/gcc/4.9.3 --with-CXX_DEBUG=-g --with-C_OPTIMIZE=-O0 --with-CXX_OPTIMIZE=-O0 --enable-languages=c++,fortran
Before you debug your own translators, you may want to doublecheck if ROSE's builtin translator (rose-compiler) can handle your input code properly. If not, you should report the bug to the ROSE team.
If rose-compiler can handle it but your customized translator cannot. The problem may be caused by the customizations you introduced in your translators.
Another thing is to reduce your input code to be as small as possible so it can just trigger the error you are interested in. This will simplify the bug hunting process dramatically. It is very difficult to debug a translator processing thousands of lines of code.
Basics of GDB[edit | edit source]
gdb is a debugger. It provides a controlled execution environment for you to inspect if your program is running the way you expected.
Essentially, it allows you to:
- run your program within a controlled debugging environment: using gdb—args <program> <args...>
- or libtool—mode=execute gdb—args <progra> <args...> for libtool built executables.
- stop at desired execution points
- normal breakpoints (called breakpoints): using break <where>, <where> can be a function name, line_number, or file:line_number.
- when value changes for a given variable(called watchpoint): using watch <where>
- segmentation fault : this will happen automatically, so you can inspect how a seg fault happens
- assertion failure: this will happen automatically, so you can debug assertion failures.
- inspect and even change things like variables, types, etc. once your program stops at desired execution points
- inspect the call stack at the breakpoint: using backtrace or bt in short. frame <frame#> to go to the stack frame of your interests.
- look around relevant source code near the breakpoint: using list [+|-|filename:linenumber|filename:function]
- inspect the values of variables and expressions: using print <what>, <what> can be any variable, expression, or even function call.
- inspect the type of a variable: whatis variable_name
- change the content of a variable to a given value: set <var_name>=<value>
- call functions: using print function_name, this is helpful to call some dump functions for some class objects.
- control the execution further
- step one statement at a time, through the execution of your program: you can step through at the current frame (next), step down into a frame (step), or step out the current stack frame (finish),
- continue the execution until next breakpoint or watchpoint: using continue or c in short
- return from a function immediately, passing a given value: return <expression>
- and other things.
For a quick overview, you can look through a cheat sheet online:
From Rob, There is a curses-based wrapper called "cgdb" [1].
- You get a split window: the bottom is the GDB console and the top is syntax-highlighted source code that automatically tracks your current location and supports PageUp/PageDn, which is a lot easier to use than GDB's "list" command.
- it requires ncurses-devl and readline-devel to install.
A translator not built by ROSE's build system[edit | edit source]
This is also called out-of-sourcetree build for some people.
If the translator is built using a makefile without using libtool. The debugging steps of your translator are just classic steps to use gdb.
- Make sure your translator is compiled with the GNU debugging option -g so there is debugging information in your object codes
These are the steps of a typical debugging session:
1. Set a breakpoint
2. Examine the execution path to make sure the program goes through the path that you expected
3. Examine the local data to validate their values
# how to print out information about a AST node #------------------------------------- (gdb) print n $1 = (SgNode *) 0xb7f12008 # Check the type of a node #------------------------------------- (gdb) print n->sage_class_name() $2 = 0x578b3af "SgFile" (gdb) print n->get_parent() $7 = (SgNode *) 0x95e75b8 # Convert a node to its real node type then call its member functions #--------------------------- (gdb) isSgFile(n)->getFileName () #------------------------------------- # When displaying a pointer to an object, identify the actual (derived) type of the object # rather than the declared type, using the virtual function table. #------------------------------------- (gdb) set print object on (gdb) print astNode $6 = (SgPragmaDeclaration *) 0xb7c68008 # unparse the AST from a node # Only works for AST pieces with full scope information # It will report error if scope information is not available at any ancestor level. #------------------------------------- (gdb) print n->unparseToString() # print out Sg_File_Info #------------------------------------- (gdb) print n->get_file_info()->display()
Example 1: debugging an AST traversal[edit | edit source]
We first prepare the example ROSE-based analyzer traversing AST to find loops. Rename it to be demo.C:
- wget https://raw.githubusercontent.com/rose-compiler/rose/develop/tutorial/visitorTraversal.C
- mv visitorTraversal.C demo.C
We can look into the example analyzer's source code: cat demo.C Essentially, we can see the following content:
4 #include "rose.h"
5
6 class visitorTraversal : public AstSimpleProcessing
7 {
8 public:
9 visitorTraversal();
10 virtual void visit(SgNode* n);
11 virtual void atTraversalEnd();
12 };
13
14 visitorTraversal::visitorTraversal()
15 {
16 }
17
18 void visitorTraversal::visit(SgNode* n)
19 {
20 if (isSgForStatement(n) != NULL)
21 {
22 printf ("Found a for loop ... \n");
23 }
24 }
25
26 void visitorTraversal::atTraversalEnd()
27 {
28 printf ("Traversal ends here. \n");
29 }
30
31 int
32 main ( int argc, char* argv[] )
33 {
34 // Initialize and check compatibility. See Rose::initialize
35 ROSE_INITIALIZE;
36
37 if (SgProject::get_verbose() > 0)
38 printf ("In visitorTraversal.C: main() \n");
39
40 SgProject* project = frontend(argc,argv);
41 ROSE_ASSERT (project != NULL);
42
43 // Build the traversal object
44 visitorTraversal exampleTraversal;
45
46 // Call the traversal function (member function of AstSimpleProcessing)
47 // starting at the project node of the AST, using a preorder traversal.
48 exampleTraversal.traverseInputFiles(project,preorder);
49
50 return 0;
51 }
A ROSE-based tool initializes ROSE first (at line 35). Then the frontend() function is called to parse an iput code and generate an AST rooted at project of SgProject type (at line 40).
After that, a traversal object is declared at line 44. The object is used to traverse the input files of the project, using a preorder traversal.
The traversal object is based on a derived visitorTraversal class at line 6. This derived class has member functions to define what should happen during construction (line 14), visiting a node (line 18), and the end of the traversal (line 26).
Now get a sample makefile to build the source file into an executable file:
The makefile should be self-explanatory. It uses rose-config in the installation path to set various environment variables for compilers, compilation and linking flags, library path, etc.
Get an example input code for the analyzer:
- wget https://raw.githubusercontent.com/rose-compiler/rose/develop/tutorial/inputCode_ExampleTraversals.C
The input code has two for-loops at line 20 and 41, as shown at link
Prepare the environment variable used to specify where ROSE is installed.
- export ROSE_HOME=/home/freecc/install/rose_install
Build the analyzer:
- make -f SampleMakefile
There should be an executable file named demo under the current directory:
Finally, run the demo analyzer to process the example input code:
- ./demo -c inputCode_ExampleTraversals.C
The analyzer should find two for loops and report the end of the traveral.
Found a for loop ... Found a for loop ... Traversal ends here.
Debug The Translator[edit | edit source]
Now let's debug this simple translator.
First of all, use gdb -args to run the translator with options
gdb -args ./demo -c inputCode_ExampleTraversals.C
// r means run: It is usually a good practice to run the program without setting breakpoints first to see if it can run normally
// Or to reproduce an assertion error or seg fault
(gdb) r
Starting program: /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/./demo -c inputCode_ExampleTraversals.C
...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Found a for loop ...
Found a for loop ...
Traversal ends here.
[Inferior 1 (process 44697) exited normally]
...
(gdb)
// This program has no errors. So we set a break point at line 22 of demo.C
(gdb) b demo.C:22
Breakpoint 1 at 0x40b0e2: file demo.C, line 22.
// We expect this breakpoint will be hit twice since the input code has only two loops. We try to verify this:
(gdb) r
Starting program: /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/./demo -c inputCode_ExampleTraversals.C
warning: File "/nfs/casc/overture/ROSE/opt/rhel7/x86_64/gcc/4.9.3/mpc/1.0/mpfr/3.1.2/gmp/5.1.2/lib64/libstdc++.so.6.0.20-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, visitorTraversal::visit (this=0x7fffffffb430, n=0x7fffe87db010) at demo.C:22
22 printf ("Found a for loop ... \n");
// Hit breakpoint 1 once, try to continue to see what will happen
(gdb) c
Continuing.
Found a for loop ...
Breakpoint 1, visitorTraversal::visit (this=0x7fffffffb430, n=0x7fffe87db138) at demo.C:22
22 printf ("Found a for loop ... \n");
// Hit breakpoint 1 for the second time, try to continue
(gdb) c
Continuing.
Found a for loop ...
Traversal ends here.
[Inferior 1 (process 46262) exited normally]
// The program terminates now , no more stop at breakpoint 1.
// ----------now we inspect the variable n at the breakpoint 1
// return the program and hit Breakpoint 1
(gdb) r
Breakpoint 1, visitorTraversal::visit (this=0x7fffffffb430, n=0x7fffe87db010) at demo.C:22
22 printf ("Found a for loop ... \n");
//print out the casted n : it is indeed a SgForStatement
(gdb) p isSgForStatement(n)
$1 = (SgForStatement *) 0x7fffe87db010
// Inspect the file info of this ForStatement, understanding where it is coming from in the source code.
(gdb) p isSgForStatement(n)->get_file_info()->display()
Inside of Sg_File_Info::display() of this pointer = 0x7fffe94d58b0
isTransformation = false
isCompilerGenerated = false
isOutputInCodeGeneration = false
isShared = false
isFrontendSpecific = false
isSourcePositionUnavailableInFrontend = false
isCommentOrDirective = false
isToken = false
isDefaultArgument = false
isImplicitCast = false
filename = /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/inputCode_ExampleTraversals.C
line = 20 column = 6
physical_file_id = 0 = /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/inputCode_ExampleTraversals.C
physical_line = 20
source_sequence_number = 8726
$2 = void
Inspect post_construction_intialization()[edit | edit source]
Breakpoints at the post_construction_initialization () are useful to inspect when a node is created and/or if a node has required fields set after construction. For example, going through the callstack (using up and down command in gdb) leading to this function call can inspect if the node has parent or scope pointers set. If not, you can add such operations to fix bugs related NULL pointers.
// ----------- We want to inspect when the SgForStatement nodes are created in the execution
// set a breakpoint at the post_construciton_initialization() method of SgForStatement
(gdb) b SgForStatement::post_construction_initialization()
Breakpoint 2 at 0x7ffff3d6495f: file Cxx_Grammar.C, line 139566.
// Disable Breapoint 1 for now
(gdb) disable 1
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep n 0x000000000040b0e2 in visitorTraversal::visit(SgNode*) at demo.C:22
breakpoint already hit 1 time
2 breakpoint keep y 0x00007ffff3d6495f in SgForStatement::post_construction_initialization() at Cxx_Grammar.C:139566
// run until the Breakpoint 2 is hit
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Breakpoint 2, SgForStatement::post_construction_initialization (this=0x7fffe87db010) at Cxx_Grammar.C:139566
139566 if (p_for_init_stmt == NULL) {
// use backtrace to check the function call stacks leading to this stop of Breakpoint 2.
// You can clearly see the callchain from main() all the way to the breakpoint.
(gdb) bt
#0 SgForStatement::post_construction_initialization (this=0x7fffe87db010) at Cxx_Grammar.C:139566
#1 0x00007ffff54e55d8 in SgForStatement::SgForStatement (this=0x7fffe87db010, test=0x0, increment=0x0, loop_body=0x0)
at Cxx_GrammarNewConstructors.C:5258
#2 0x00007ffff5bb04ce in EDG_ROSE_Translation::parse_statement (sse=..., existingBasicBlock=0x0)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:49637
#3 0x00007ffff5bbb5ea in EDG_ROSE_Translation::parse_statement_list (sse=..., orig_kind=iek_statement, orig_ptr=0x115f810)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:53079
#4 0x00007ffff5bb0221 in EDG_ROSE_Translation::parse_statement (sse=..., existingBasicBlock=0x7fffe8934010)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:49492
#5 0x00007ffff5c09217 in EDG_ROSE_Translation::parse_function_body<SgFunctionDeclaration> (sse_base=..., p=0x1151ad0, decl=0x7fffe9e21698)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:36262
#6 0x00007ffff5b844fa in EDG_ROSE_Translation::convert_routine (p=0x1151ad0, forceTemplateDeclaration=false, edg_template=0x0,
optional_nondefiningTemplateDeclaration=0x0) at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:34343
#7 0x00007ffff5b703cf in EDG_ROSE_Translation::parse_routine (sse=..., forceTemplateDeclaration=false, edg_template=0x0, forceSecondaryDeclaration=false)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:29866
#8 0x00007ffff5be6f78 in EDG_ROSE_Translation::parse_global_or_namespace_scope_entity (sse=...)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:64638
#9 0x00007ffff5bea2df in EDG_ROSE_Translation::parse_global_scope (inputGlobalScope=0x7ffff7ec3120, sse=..., skip_ast_translation=false)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:65427
#10 0x00007ffff5bedbee in sage_back_end (sageFile=...) at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:66777
#11 0x00007ffff5beea8a in cfe_main (argc=44, argv=0x702f80, sageFile=...)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:66992
#12 0x00007ffff5beebe7 in edg_main (argc=44, argv=0x702f80, sageFile=...)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:67093
#13 0x00007ffff3c14629 in SgSourceFile::build_C_and_Cxx_AST (this=0x7fffeb45e010, argv=..., inputCommandLine=...)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:5430
#14 0x00007ffff3c1587a in SgSourceFile::buildAST (this=0x7fffeb45e010, argv=..., inputCommandLine=...)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:5983
#15 0x00007ffff3c0e5b7 in SgFile::callFrontEnd (this=0x7fffeb45e010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:3119
#16 0x00007ffff3c0b576 in SgSourceFile::callFrontEnd (this=0x7fffeb45e010)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2137
#17 0x00007ffff3c0a005 in SgFile::runFrontend (this=0x7fffeb45e010, nextErrorCode=@0x7fffffffaadc: 0)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:1606
#18 0x00007ffff3c12924 in Rose::Frontend::RunSerial (project=0x7fffeb555010)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:4613
#19 0x00007ffff3c12593 in Rose::Frontend::Run (project=0x7fffeb555010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:4506
#20 0x00007ffff3c0b84d in SgProject::RunFrontend (this=0x7fffeb555010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2209
#21 0x00007ffff3c0bcb2 in SgProject::parse (this=0x7fffeb555010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2334
#22 0x00007ffff3c0b0d4 in SgProject::parse (this=0x7fffeb555010, argv=...)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2028
#23 0x00007ffff3cbd2e9 in SgProject::SgProject (this=0x7fffeb555010, argv=..., frontendConstantFolding=false) at Cxx_Grammar.C:29114
#24 0x00007ffff645fd54 in frontend (argv=..., frontendConstantFolding=false) at ../../../sourcetree/src/roseSupport/utility_functions.C:628
#25 0x00007ffff645fc10 in frontend (argc=3, argv=0x7fffffffb578, frontendConstantFolding=false)
at ../../../sourcetree/src/roseSupport/utility_functions.C:590
#26 0x000000000040b152 in main (argc=3, argv=0x7fffffffb578) at demo.C:40
(gdb)
// Again, Breakpoint 2 will be hit twice since we only have two for loops in the input code
(gdb) c
Continuing.
Breakpoint 2, SgForStatement::post_construction_initialization (this=0x7fffe87db138) at Cxx_Grammar.C:139566
139566 if (p_for_init_stmt == NULL) {
(gdb) c
Continuing.
Found a for loop ...
Found a for loop ...
Traversal ends here.
[Inferior 1 (process 47292) exited normally]
Set a condition to Breakpoints[edit | edit source]
In real codes, there are hundreds of objects of same class type (e.g. SgForStatement). Many of them come from header files and will be present in AST. We should only stop when it mathes the one we want to inspect. Often, we can use the memory address of the object as a condition.
// Add a condition to Breakpoint 2: stop only when the this pointers is equal to a memory address
(gdb) cond 2 (unsigned long)this==(unsigned long)0x7fffe87db138
// run the program: now it will stop only when the condition for Breakpoint 2 is met, skipping all other hits to Breakpoint 2.
(gdb) r
Starting program: /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/./demo -c inputCode_ExampleTraversals.C
..
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 2, SgForStatement::post_construction_initialization (this=0x7fffe87db138) at Cxx_Grammar.C:139566
139566 if (p_for_init_stmt == NULL) {
// continue the execution, after doing inspections you want. It should go to the normal termination, skipping other hits to Breakpoint 2.
(gdb) c
Continuing.
Found a for loop ...
Found a for loop ...
Traversal ends here.
[Inferior 1 (process 47785) exited normally]
Use Watchpoints[edit | edit source]
You can use a watchpoint to stop execution whenever the value of an expression changes, without having to predict a particular place where this may happen. (This is sometimes called a data breakpoint.)
Watchpoints can be treated as special types of breakpoints. They will stop when the watched memory locations have value changes. This is especially useful when you want to know when some variable (or field of an object) is set to some value or cleared its value. For example, often a bug is related to some NULL value of some fields of a node. The fields may be set during construction of the node. But later mysteriously one field becomes NULL. It is extremely hard to find when this happens without using watchpoint.
For example, we want to watch the value changes to the parent field of the SgForStatement matching the memory address of the 2nd loop.
- We first stop at a breakpoint where we have access to the node's internal fields. This usually is done by stopping at SgForStatement::post_construction_initialization ().
- Once the internal variables are visible in gdb at the proper breakpoint, we can grab the memory address of the internal variable. This requires your knowledge of how internal variables are named. You can either look at the class declaration of the object, or guess it by convention. For example, mostly something with an access function like get_something() has a corresponding internal variable named p_something in ROSE AST node types.
- Finally, we have to watch the deferenced value of the memory address (watch *address). Watching the memory address (watch address) is to watch a constant value. It won't work.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep n 0x000000000040b0e2 in visitorTraversal::visit(SgNode*) at demo.C:22
2 breakpoint keep y 0x00007ffff3d6495f in SgForStatement::post_construction_initialization() at Cxx_Grammar.C:139566
stop only if (unsigned long)this==(unsigned long)0x7fffe87db138
breakpoint already hit 1 time
(gdb) r
Starting program: /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/./demo -c inputCode_ExampleTraversals.C
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 2, SgForStatement::post_construction_initialization (this=0x7fffe87db138) at Cxx_Grammar.C:139566
139566 if (p_for_init_stmt == NULL) {
// the data member storing parent pointer of an AST node is p_parent
// it is now have NULL value
(gdb) p p_parent
$3 = (SgNode *) 0x0
// we obtain the memory address of p_parent
(gdb) p &p_parent
$4 = (SgNode **) 0x7fffe87db140
// watch value changes of this address
// Must deference the address with * , or it will won't work by saying "Cannot watch constant value"
(gdb) watch *0x7fffe87db140
// We can now watch the value changes to this memory address
// Let's restart the program from the beginning:
(gdb) r
Starting program: /home/liao6/workspace/rose/2019-10-31_14-16-05_-0700/myTranslator/./demo -c inputCode_ExampleTraversals.C
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Hardware watchpoint 2: *0x7fffe87db140
Old value = <unreadable>
New value = 0
SgNode::SgNode (this=0x7fffe87db138) at Cxx_Grammar.C:2128
2128 p_isModified = false;
// we check when the first time its value is changed: the constructor of ancestor node SgNode
(gdb) bt
#0 SgNode::SgNode (this=0x7fffe87db138) at Cxx_Grammar.C:2128
#1 0x00007ffff3d19f01 in SgLocatedNode::SgLocatedNode (this=0x7fffe87db138, startOfConstruct=0x0) at Cxx_Grammar.C:85278
#2 0x00007ffff3d59798 in SgStatement::SgStatement (this=0x7fffe87db138, startOfConstruct=0x0) at Cxx_Grammar.C:134029
#3 0x00007ffff3d59fcc in SgScopeStatement::SgScopeStatement (this=0x7fffe87db138, file_info=0x0) at Cxx_Grammar.C:134289
#4 0x00007ffff54e54e0 in SgForStatement::SgForStatement (this=0x7fffe87db138, test=0x0, increment=0x0, loop_body=0x0)
at Cxx_GrammarNewConstructors.C:5230
#5 0x00007ffff5bb04ce in EDG_ROSE_Translation::parse_statement (sse=..., existingBasicBlock=0x0)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:49637
#6 0x00007ffff5bbb5ea in EDG_ROSE_Translation::parse_statement_list (sse=..., orig_kind=iek_statement, orig_ptr=0x1162200)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:53079
#7 0x00007ffff5bb0221 in EDG_ROSE_Translation::parse_statement (sse=..., existingBasicBlock=0x7fffe8934470)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:49492
#8 0x00007ffff5c09217 in EDG_ROSE_Translation::parse_function_body<SgFunctionDeclaration> (sse_base=..., p=0x1151fc0, decl=0x7fffe9e21e68)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:36262
#9 0x00007ffff5b844fa in EDG_ROSE_Translation::convert_routine (p=0x1151fc0, forceTemplateDeclaration=false, edg_template=0x0,
optional_nondefiningTemplateDeclaration=0x0) at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:34343
#10 0x00007ffff5b703cf in EDG_ROSE_Translation::parse_routine (sse=..., forceTemplateDeclaration=false, edg_template=0x0, forceSecondaryDeclaration=false)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:29866
#11 0x00007ffff5be6f78 in EDG_ROSE_Translation::parse_global_or_namespace_scope_entity (sse=...)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:64638
#12 0x00007ffff5bea2df in EDG_ROSE_Translation::parse_global_scope (inputGlobalScope=0x7ffff7ec3120, sse=..., skip_ast_translation=false)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:65427
#13 0x00007ffff5bedbee in sage_back_end (sageFile=...) at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:66777
#14 0x00007ffff5beea8a in cfe_main (argc=44, argv=0x702f80, sageFile=...)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:66992
#15 0x00007ffff5beebe7 in edg_main (argc=44, argv=0x702f80, sageFile=...)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:67093
#16 0x00007ffff3c14629 in SgSourceFile::build_C_and_Cxx_AST (this=0x7fffeb45e010, argv=..., inputCommandLine=...)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:5430
#17 0x00007ffff3c1587a in SgSourceFile::buildAST (this=0x7fffeb45e010, argv=..., inputCommandLine=...)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:5983
#18 0x00007ffff3c0e5b7 in SgFile::callFrontEnd (this=0x7fffeb45e010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:3119
#19 0x00007ffff3c0b576 in SgSourceFile::callFrontEnd (this=0x7fffeb45e010)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2137
#20 0x00007ffff3c0a005 in SgFile::runFrontend (this=0x7fffeb45e010, nextErrorCode=@0x7fffffffaadc: 0)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:1606
#21 0x00007ffff3c12924 in Rose::Frontend::RunSerial (project=0x7fffeb555010)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:4613
#22 0x00007ffff3c12593 in Rose::Frontend::Run (project=0x7fffeb555010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:4506
#23 0x00007ffff3c0b84d in SgProject::RunFrontend (this=0x7fffeb555010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2209
#24 0x00007ffff3c0bcb2 in SgProject::parse (this=0x7fffeb555010) at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2334
#25 0x00007ffff3c0b0d4 in SgProject::parse (this=0x7fffeb555010, argv=...)
at ../../../../sourcetree/src/frontend/SageIII/sage_support/sage_support.cpp:2028
#26 0x00007ffff3cbd2e9 in SgProject::SgProject (this=0x7fffeb555010, argv=..., frontendConstantFolding=false) at Cxx_Grammar.C:29114
#27 0x00007ffff645fd54 in frontend (argv=..., frontendConstantFolding=false) at ../../../sourcetree/src/roseSupport/utility_functions.C:628
#28 0x00007ffff645fc10 in frontend (argc=3, argv=0x7fffffffb578, frontendConstantFolding=false)
at ../../../sourcetree/src/roseSupport/utility_functions.C:590
#29 0x000000000040b152 in main (argc=3, argv=0x7fffffffb578) at demo.C:40
// We continue the execution
(gdb) c
Continuing.
Hardware watchpoint 2: *0x7fffe87db140
Old value = 0
New value = -393001872
SgNode::set_parent (this=0x7fffe87db138, parent=0x7fffe8934470) at Cxx_Grammar.C:1684
1684 if ( ( variantT() == V_SgClassDeclaration ) && ( parent != NULL && parent->variantT() == V_SgFunctionParameterList ) )
// Now we found that this p_parent field is set by calling set_parent(). We can inspect the call stack and other things of interests
(gdb) bt
#0 SgNode::set_parent (this=0x7fffe87db138, parent=0x7fffe8934470) at Cxx_Grammar.C:1684
#1 0x00007ffff5bb04ef in EDG_ROSE_Translation::parse_statement (sse=..., existingBasicBlock=0x0)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:49643
#2 0x00007ffff5bbb5ea in EDG_ROSE_Translation::parse_statement_list (sse=..., orig_kind=iek_statement, orig_ptr=0x1162200)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:53079
#3 0x00007ffff5bb0221 in EDG_ROSE_Translation::parse_statement (sse=..., existingBasicBlock=0x7fffe8934470)
at ../../../../../../sourcetree/src/frontend/CxxFrontend/EDG/edgRose/edgRose.C:49492
.... // omitted
(gdb) c
Continuing.
Found a for loop ...
Found a for loop ...
Traversal ends here.
[Inferior 1 (process 54495) exited normally]
// No more value changes to the same memory address, as expected.
A translator shipped with ROSE[edit | edit source]
This is also called in-tree or in-sourcetree build. libtool is used to build the translators.
ROSE turns on -O2 and -g by default so the translators shipped with ROSE should already have some debugging information available. But some variables may be optimized away. To preserve the max debugging information, you may have to reconfigure/recompile rose to turn off optimizations.
../sourcetree/configure—with-CXX_DEBUG=-g --with-C_OPTIMIZE=-O0—with-CXX_OPTIMIZE=-O0 ...
ROSE uses libtool so the executables in the build tree are not real—they're simply wrappers around the actual executable files. You have two choices:
- Find the real executable in the .lib directory then debug the real executables there
- Use libtool command line as follows:
$ libtool --mode=execute gdb --args ./built_in_translator file1.c
If you can set up alias command in your .bashrc, add the following:
alias debug='libtool --mode=execute gdb -args'
then all your debugging sessions can be as simple as
$ debug ./built_in_translator file1.c
The remaining steps are the same as a regular gdb session with the typical operations, such as breakpoints, printing data, etc.
Example 2: Fixing a real bug in ROSE[edit | edit source]
1. Reproduce the reported bug:
$ make check
...
./testVirtualCFG \
--edg:no_warnings -w -rose:verbose 0 --edg:restrict \
-I$ROSE/tests/CompileTests/virtualCFG_tests/../Cxx_tests \
-I$ROSE/sourcetree/tests/CompileTests/A++Code \
-c $ROSE/sourcetree/tests/CompileTests/virtualCFG_tests/../Cxx_tests/test2001_01.C
...
lt-testVirtualCFG: $ROSE/src/frontend/SageIII/virtualCFG/virtualCFG.h:111:
VirtualCFG::CFGEdge::CFGEdge(VirtualCFG::CFGNode, VirtualCFG::CFGNode):
Assertion `src.getNode() != __null && tgt.getNode() != __null' failed.
Ah, so we've failed an assertion within the virtualCFG.h header file on line 111:
Assertion `src.getNode() != __null && tgt.getNode() != __null' failed
And the error was produced by running the lt-testVirtualCFG libtool executable translator, i.e. the actual translator name is testVirtualCFG (without the lt- prefix).
2. Run the same translator command line with Libtool to start a GDB debugging session:
$ libtool --mode=execute gdb --args ./testVirtualCFG \
--edg:no_warnings -w -rose:verbose 0 --edg:restrict \
-I$ROSE/tests/CompileTests/virtualCFG_tests/../Cxx_tests \
-I$ROSE/sourcetree/tests/CompileTests/A++Code \
-c $ROSE/sourcetree/tests/CompileTests/virtualCFG_tests/../Cxx_tests/test2001_01.C
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5_8.1)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ${ROSE_BUILD_TREE}tests/CompileTests/virtualCFG_tests/.libs/lt-testVirtualCFG...done.
(gdb)
The GDB session has started, and we're provided with a command line prompt to begin our debugging.
3. Let's run the program, which will hit the failed assertion:
(gdb) r
Starting program: \
${ROSE_BUILD_TREE}/tests/CompileTests/virtualCFG_tests/.libs/lt-testVirtualCFG \
--edg:no_warnings -w -rose:verbose 0 --edg:restrict \
-I${ROSE}/tests/CompileTests/virtualCFG_tests/../Cxx_tests \
-I../../../../sourcetree/tests/CompileTests/A++Code
-c ${ROSE}/tests/CompileTests/virtualCFG_tests/../Cxx_tests/test2001_01.C
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000
[Thread debugging using libthread_db enabled]
lt-testVirtualCFG: ${ROSE}/src/frontend/SageIII/virtualCFG/virtualCFG.h:111:
VirtualCFG::CFGEdge::CFGEdge(VirtualCFG::CFGNode, VirtualCFG::CFGNode): Assertion `src.getNode() != __null && tgt.getNode() != __null' failed.
Program received signal SIGABRT, Aborted.
0x0000003752230285 in raise () from /lib64/libc.so.6
Okay, we've reproduced the problem in our GDB session.
4. Let's check the backtrace to see how we wound up at this failed assertion:
(gdb) bt
#0 0x0000003752230285 in raise () from /lib64/libc.so.6
#1 0x0000003752231d30 in abort () from /lib64/libc.so.6
#2 0x0000003752229706 in __assert_fail () from /lib64/libc.so.6
#3 0x00002aaaad6437b2 in VirtualCFG::CFGEdge::CFGEdge (this=0x7fffffffb300, src=..., tgt=...)
at ${ROSE}/../src/frontend/SageIII/virtualCFG/virtualCFG.h:111
#4 0x00002aaaad643b60 in makeEdge<VirtualCFG::CFGNode, VirtualCFG::CFGEdge> (from=..., to=..., result=...)
at ${ROSE}/../src/frontend/SageIII/virtualCFG/memberFunctions.C:82
#5 0x00002aaaad62ef7d in SgReturnStmt::cfgOutEdges (this=0xbfaf10, idx=1)
at ${ROSE}/../src/frontend/SageIII/virtualCFG/memberFunctions.C:1471
#6 0x00002aaaad647e69 in VirtualCFG::CFGNode::outEdges (this=0x7fffffffb530)
at ${ROSE}/../src/frontend/SageIII/virtualCFG/virtualCFG.C:636
#7 0x000000000040bf7f in getReachableNodes (n=..., s=...) at ${ROSE}/tests/CompileTests/virtualCFG_tests/testVirtualCFG.C:13
...
5. Next, we'll move backwards (or upwards) in the program to get to the point of assertion:
(gdb) up
#1 0x0000003752231d30 in abort () from /lib64/libc.so.6
(gdb) up
#2 0x0000003752229706 in __assert_fail () from /lib64/libc.so.6
(gdb) up
#3 0x00002aaaad6437b2 in VirtualCFG::CFGEdge::CFGEdge (this=0x7fffffffb300, src=..., tgt=...)
at ${ROSE}/src/frontend/SageIII/virtualCFG/virtualCFG.h:111
111 CFGEdge(CFGNode src, CFGNode tgt): src(src), tgt(tgt) \
{ assert(src.getNode() != NULL && tgt.getNode() != NULL); }
Okay, so the assertion is inside of a constructor for CFGEdge:
CFGEdge(CFGNode src, CFGNode tgt): src(src), tgt(tgt) \
{
assert(src.getNode() != NULL && tgt.getNode() != NULL); # This is the failed assertion
}
Unfortunately, we can't tell at a glance which of the two conditions in the assertion is failing.
6. Figure out why the assertion is failing:
Let's examine the two conditions in the assertion:
(gdb) p src.getNode() $1 = (SgNode *) 0xbfaf10
So src.getNode() is returning a non-null pointer to an SgNode. How bout tgt.getNode()?
(gdb) p tgt.getNode() $2 = (SgNode *) 0x0
Ah, there's the culprit. So for some reason, tgt.getNode() is returning a null SgNode pointer (0x0).
From here, we used the GDB up command to backtrace in the program to figure out where the node returned by tgt.getNode() was assigned a NULL value.
We eventually found a call to SgReturnStmt::cfgOutEdges which returns a variable, called enclosingFunc. In the source code, there's currently no assertion to check the value of enclosingFunc, and that's why we received the assertion later on in the program. As a side note, it is good practice to add assertions as soon as possible in your source code so in times like this, we don't have to spend time unnecessarily back-tracing.
After adding the assertion for enclosingFunc, we run the program again to reach this new assertion point:
lt-testVirtualCFG: ${ROSE}sourcetree/src/frontend/SageIII/virtualCFG/memberFunctions.C:1473: \
virtual std::vector<VirtualCFG::CFGEdge, std::allocator<VirtualCFG::CFGEdge> > \
SgReturnStmt::cfgOutEdges(unsigned int): \
Assertion `enclosingFunc != __null' failed.
Okay, it's failing so we know that the assignment to enclosingFunc is NULL.
# enclosingFunc is definitely NULL (0x0) (gdb) p enclosingFunc $1 = (SgFunctionDefinition *) 0x0 # What is the current context? (gdb) p this $2 = (SgReturnStmt * const) 0xbfaf10
Okay, we're inside of an SgReturnStmt object. Let's set a break point where enclosingFunc is being assigned to:
Breakpoint 1, SgReturnStmt::cfgOutEdges (this=0xbfaf10, idx=1) at ${ROSE}/src/frontend/SageIII/virtualCFG/memberFunctions.C:1472
1472 SgFunctionDefinition* enclosingFunc = SageInterface::getEnclosingProcedure(this);
So this is the line we're examining:
SgFunctionDefinition* enclosingFunc = SageInterface::getEnclosingProcedure(this);
So the NULL value must be coming from SageInterface::getEnclosingProcedure(this);.
After code reviewing the function getEnclosingProcedure, we discovered a flaw in the algorithm.
The function tries to return a SgNode which is the enclosing procedure of the specified type, SgFunctionDefinition. However, upon checking the function's state at the point of return, we see that it incorrectly detected a SgBasicBlack as the enclosing procedure for the SgReturnStmt.
(gdb) p parent->class_name()
$12 = {static npos = 18446744073709551615,
_M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x7cd0e8 "SgBasicBlock"}}
Specifically, the last piece: 0x7cd0e8 "SgBasicBlock".
But this is wrong because we're looking for SgFunctionDefinition, not SgBasicBlock.
Upon further examination, we figured out that the function simply returned the first enclosing node it found, and not the first enclosing node that matched the user's criteria.
We added the necessary logic to make the function complete, tested it to verify its correctness, and then resolved the bug.