GDB HINTS

Hints for using gdb on CDF offline code on Linux. This works both at Fermilab and offsite. No license needed

Sofware changes quickly, check the date of this document (bottom of page) !

• This page describes my experience in trying to use gdb on the basic offline example from the CDF Offline guide CDF5924. All examples I make refer to the program ExampleMyModule described in that note. In particular I did the following:

  setup cdfsoft2 4.2.0
  cd ~
  newrel -t 4.2.0 420
  cd 420
  addpkg -h ExampleMyModule
  gmake
  

• a nice introduction to problematics of various debuggers on CDF code is in Robert Kennedy's Debugger mini how-to
• As of February 15, 2002, there is no gdb in Fnal KITS that works with KAI. But there is one gdb executable that works, compiled by Robert Kenendy in fcdfsgi2.fnal.gov:~kennedy/Debuggers/gdbkcc-5.0k3a-frhlinux6.1 which can copied e.g. with kerberized rcp by everybody in CDF.
• that version of gdb can be used in 3 ways, i.e. with 3 different interfaces (front end). In any case you should fix the path so that the proper gdb is used. I.e. Unix command "which gdb" should list Robert's executable or a proper copy, and, until further notice, avoid any setup gdb command. After that, gdb can be used in 3 ways:
  • standalone: see Robert's mini how-to. Basic, but robust. See also an example
  • with ddd GUI: see Robert's mini how-to. Very nice GUI, takes only a bit of learning.
  • within (X)Emacs see later. No additional window needed. Program steps are indicated in the editor window. Faster then ddd, but more suited for small quick things.
• no matter the interface you use, you will always use the same gdb commands. So the previous example applies to all methods.
• there is a gdb manual available on line, unfortuntaly I found gdb to behave slightly differently from what that says, in particular for breakpoints, see the following tips.
• no debugger will help against CDF niceties like when inside the loop on tracks (e.g. in ExampleMyModule) there is no way to know how many tracks are there and how far you are in iterating the loop.

Common tips:

• .dbginit make a .dbginit file in your login directory with the line
  set demangle_style edg
  this prevents you from having to issue that command to the dbg prompt every time
• EnterWhen you type the Enter key to the (gdb) prompt, the last gdb command you issued is executed again.
• BreakPoints No matter which iterface to gdb you use, the easiest way to set breakpoints is the command
  break <entry_point>

   Example:
     break main
   one the program is running and stops at your favorite entry point
   (i.e. function/method name) the source is loaded in the gdb and you
   can set further breakpoints with the command 
     break NNN     where NNN is the line number you want to stop at
   Example:     break 132
   There is one problem with C++, entry points are not simply the method
   names, becasue of overloading also thse arguments have to be indicated
   with the proper name. I.e.:
     break main                                        is OK (as any C function)
     break ExampleTrackAnalysis::event                 is not valid
     break ExampleTrackAnalysis::(AbsEvent* anEvent)   does not work either !
     break ExampleTrackAnalysis::(AbsEvent* event)     does not work either !
   Apparently none of the ways ExampleTrackAnalysis::event appears in the
   offline favorite example ExampleMyModule.cc or ExampleMyModule.hh is
   accepted by gdb.
   The way out I found is to use gdb automatic name completion. Type:
      bre 'ExampleTrackAnalysis::event<TAB>
   Note the single quote ! When you press the TAB key gdb will complete
   the name to
      break 'ExampleTrackAnalysis::event(EventRecord *)'
   which works.
   Note that the single quote is the one on the double quote key, next
   to colon, on the right side of the keyboard. Not the one on the ~ key,
   this latter one will not work.
   

• setenv USESHLIBS 1 If you use dynamic loaded libraries, aka shared libraries, your favorite module is not loaded until the program runs, so gdb knows nothing about it and you can not set a breakpoint in ExampleTrackAnalysis before starting. You have to do:

   (gdb) break main
   (gdb) run ExampleMyModule/run.tcl
  

  then the program runs until...

  Breakpoint 1, main (argc=2, argv=0xbfffb7d4)
      at /home/cdfsoft/dist/packages/Framework/V00-06-98/src/APPMain.cc:90
  90      in /home/cdfsoft/dist/packages/Framework/V00-06-98/src/APPMain.cc
  

  at which point the libExampleMyModule.so is loaded and you can do

   (gdb) bre 'ExampleTrackAnalysis::event(EventRecord *)'
   Breakpoint 2 at 0x4002203c: file /home/belforte/420/ExampleMyModule/ExampleTrackAnalysis.cc, line 111.
  

Using gdb in (X)Emacs

• Open the editor for your favorite source file. Then click on the Tools menu and select Debug (GDB)...
  
• A pop up window with a file browser will appear prompting you to specity the executable. You can use the space bar at the prompt for automatic file name completion. You need the full path there, so the executable to load is e.g. /home/belforte/420/bin/Linux2-KCC_4_0/ExampleMyModule_test
• Once the binary is selected the file window will be replaced by the gdb window.
  
• Wait for the (gdb) prompt (about ten seconds).
  
• At the (gdb) prompt you should set the first break point (brea main e.g.) and then type run followed by any argument you would normally use when running the program, like:
  run ../../ExampleMyModule/run.tcl
  Note the ../.., this is beacuse emacs sets the current directory to the place where the executable is before starting gdb, so you are effectively runnign using /home/belforte/420/bin/Linux2-KCC_4_0 as current directory. Alternatively you just type run to the (gdb) prompt and will then need to say source ../../ExampleMyModule/run.tcl to the AC++ prompt.
• As you find bugs, and edit/save/compile again, you can reload the new exe in gdb and execute it by re-issueing the run command (better stop the current executable first with (gdb) kill), note that the argument you typed the first time is rememebered so you do not need to repeat the script path/name (you can put a different one, though).
• When the program stops at a program section in the current edited file, the gdb scope will be set to that, and the Xemacs window will be split in two.
• In the top half of the window you have the (gdb) prompt and issue gdb command as in standalone mode, and can see the program output
• In the bottom half one you still have the source. The current line will be indicated by a => in the edit window. The => prompt will move as you step trhough the program with (gdb) next, if you use (gdb) step the debugger will step inside subroutine call and the edit window will automatically go to the correct file. It will help to have xemacs set to display the line numbers. E.g. with the command <Esc>-x line-number-mode.
• On some systems (e.g. most Fermilab linux machines) the Xemacs toolbar will change when the cursor is in the (gdb) window to display "debug buttons". Most usefull are the ones with the green arrow: run, continue, step, next. Also very handy are the two next buttons with color bars and black arrow that move up/down the calls stack and thus allow to examine variables in the callers of the currently edited functions. (gdb) prompt.
• This debug toolbar is very convenient because commands are not echoed in the (gbd) window. Not having a line appear there every time you do a next helps in keeping track of other less trivial things you have been doing ! I find that toolbar one of the biggest appeal of running gdb within xeamcs rather then in standalone mode. Unfortunately I have not been able to find out how to get those handy buttons when they are not there automatically. At least on Linux RH7 I have obtained that tool bar by upd installing and then using xemacs v20_4 from KITS.

• Difficulties:
  • Shared Libraries: No matter from which current directory you start Xemacs, it will cd to the directory where the binary is before starting gdb. But the standard offline setups defines the LD_LIBRARY_PATH in such a way that the executable has to be started from the release top directory, or the shared libs are not found. You will see in the (gdb) window an error message like:

    (gdb) run
    Starting program: /home/belforte/420/bin/Linux2-KCC_4_0/ExampleMyModule_test 
    /home/belforte/420/bin/Linux2-KCC_4_0/ExampleMyModule_test: error while
    loading shared libraries: libExampleMyModule.so: cannot open shared object
    file: No such file or directory
    
    Program exited with code 0177.
    

    The way out is to tell SRT to use absolute path names, so you cd to the release top directory, then issue the command "srt_setup -a". (Thanks to Liz Sexton for this tip!)
    Example:

     belforte@fcdflnx1/~...420 > pwd
    /cdf/home/belforte/ana/420
    belforte@fcdflnx1/~...420 > echo $LD_LIBRARY_PATH
    ./shlib/Linux2-KCC_4_0:/cdf/code/cdfsoft/dist/releases/4.2.0/shlib/Linux2-KCC_4_0:./lib/Linux2-KCC_4_0:/cdf/code/cdfsoft/dist/releases/4.2.0/lib/Linux2-KCC_4_0:.:/cdf/code/cdfsoft/products/kai/v4_0f/Linux+2.2/KCC_BASE/lib:/cdf/code/cdfsoft/products/oracle_client/v8_1_6a_lite/Linux+2/lib:/cdf/code/cdfsoft/products/root/v3_01_06aKCC_4_0/Linux+2.2/lib
    belforte@fcdflnx1/~...420 > srt_setup -a
    belforte@fcdflnx1/~...420 > echo $LD_LIBRARY_PATH
    /cdf/home/belforte/ana/420/shlib/Linux2-KCC_4_0:/cdf/code/cdfsoft/dist/releases/4.2.0/shlib/Linux2-KCC_4_0:/cdf/home/belforte/ana/420/lib/Linux2-KCC_4_0:/cdf/code/cdfsoft/dist/releases/4.2.0/lib/Linux2-KCC_4_0:.:/cdf/code/cdfsoft/products/kai/v4_0f/Linux+2.2/KCC_BASE/lib:/cdf/code/cdfsoft/products/oracle_client/v8_1_6a_lite/Linux+2/lib:/cdf/code/cdfsoft/products/root/v3_01_06aKCC_4_0/Linux+2.2/lib
      

  • BreakPoints: At least in my experience, when issueing commands to gdb in the gdb part of the Xemacs window, the commands are somehow filtered by Xemacs and string completion works by completing to file names, not to entry point names. So if you try the bre 'ExampleTrackAnalysis<TAB> trick, it will not work. You need to know in advance the correct break point name.
    So while gdb within xeamcs is great with ANSI C where breakpoint is the function name and you need no help to type it, I have not used it enought with C++ to tell if this is a big or small nuisance. In any case you can get a lot of mileage from

    break ExampleTrackAnalysis::event(EventRecord *)

    possibly substituting your favorite module(s) name.