Debugging GCC Compiled Programs

Sorry, not yet complete.

This document is based on a report written as part of readme_linux_g77.doc by Rob Komar, updated to gcc 3.0 by Nick West.

First, it is strongly recommended that you switch to gcc version 3 for this allows debugger to access information in COMMON blacks. Installation instructions can be found here

Graphical Interfaces

Debugging can be made somewhat less painful by using a GUI front-end for `gdb'. Personally, I like the `ddd' graphical debugger, although other programs like gvd (another good one) xxgdb, gdbtk, tgdb, and xwpe are also available. Try them out to see if you like them. There's a slight chance that you'll have to play with the source code of some of these front-ends to enable them to handle a program the size of SNOMAN.

Name Mangling

Debugging the code produced by g77 can be difficult, and is probably the biggest stumbling block for those who want to develop SNOMAN using g77 . The `gdb' debugger is geared towards use with C/C++ code, which leads to some `interesting' results when used with Fortran code (for example, see the discussion on accessing array elements below). g77 also mangles symbols to be f2c object compatible by default (ie. it converts a symbol to lower case, appends an underscore, followed by a second one if there was an underscore already in the name).

A similar kind of mangling is done to variable names (ie. the names are converted to lower case, and those with underscores have an extra two underscores attached to the end, but names without any underscores do _NOT_ have any underscores appended to them). So, when debugging, a variable like `RTMP' would be referred to as `rtmp', and one called `RTMP_1' would be referred to as `rtmp_1__'. (Note: this is the default behaviour; it can be controlled by using the `-fno-underscoring', `-fno-second-underscore', `-fsymbol-case-*' and `-fintrin-case-*' switches with g77). When using `gdb' to debug the code, command line completion is available (using the tab key) and is helpful when trying to guess what the mangled symbol name for a variable or procedure might be.

In Fortran, arguments to subroutines and functions are usually passed using `pass-by-reference' (ie. the address of the variable is sent rather than the value). So, an argument within a subroutine must usually be accessed using pointer syntax (for example, if RTMP was passed to a subroutine, you could examine its contents using `p *rtmp' when in the subroutine's stack frame). Things get really hairy when you try to examine arrays passed as arguments to procedures. Their treatment is inconsistent in gdb, although examining the contents of the array with something like `p *arr' inside the subroutine's stack frame usually seems to work. However, sometimes an array such as ARR(3) might appear as a `(real (*)[3])' type in a subroutine, that is, as a pointer to a real[3] object. In such a case, the individual elements can be accessed as arr[0][1], arr[0][2], and arr[0][3] (ie. using a mixture of C and Fortran syntax).

The above information is summarised in the following table. Remember:-

  1. All names are converted to lower case.
  2. Names may have additional underscore (try pressing TAB to complete).
Name Type Example source gdb example
Global symbol SUBROUTINE EVMAIN To set a breakpoint:-
break evmain_
Local/global scalar variable INTEGER I_MODE To examine value:-
print i_mode_
Local/global array variable REAL DIR_COS(3) To examine DIR_COS(1):-
print dir_cos_[0]
Argument scalar variable SUBROUTINE MCG_SET_DIRECTION((I_PART,... To examine I_PART:-
print *i_part_
Argument array variable SUBROUTINE GE_NEXT(XYZ, To examine XYZ(1):-
print print *xyz[0]

Examining Hollerith Data

For example IQ{LMCTKC-4) contains 4HMCTK. To display:- x/4c iq[lmctkc-5]@4 This eXamines as 4 Characters iq[lmctkc-5] (eqv. Fortran iq(lmctkc-4)) as an address to 4 bytes of data. Not exactly intuitive! The above command displays:- 0xdc2a370 <z_+1776>: 77 'M' 67 'C' 84 'T' 75 'K'

Further Information

The info files for g77 provide a lot of useful information for debugging purposes (in particular, see the `Debugging and Interfacing' sections). It is highly recommended that you read them before attempting to debug SNOMAN code compiled by g77.

Installing GCC version 3


1)  Go to: http://www.fsf.org/software/gcc/gcc.html
    and from the download page get the tar file gcc-3.0.tar.gz

2)  Define some installation directory e.g.:-

      set INSTALLATION = "/snodata"
      mkdir -p $INSTALLATION

3)    Copy the tar file into this directory and unpack:-

      cd $INSTALLATION
      tar xvzf gcc-3.0.tar.gz

4)    Configure, build and install:-

      set srcdir = "$INSTALLATION/gcc-3.0"
      set objdir = "$INSTALLATION/gcc-bin"
      set insdir = "$INSTALLATION/usr/local"
      mkdir -p $srcdir
      mkdir -p $objdir
      mkdir -p $insdir

      cd $objdir
      $srcdir/configure --prefix=$insdir \
                        --enable-version-specific-runtime-libs
      gmake bootstrap
      gmake install

5)    Update you PATH so that the compiler is found before the system default:-

      setenv PATH $INSTALLATION/usr/local/bin:$PATH

Try typing:-

  gcc -v

you should see something like:-

  Reading specs from
  /snodata4/west/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs Configured
  with: /snodata4/west/gcc-3.0/configure --prefix=/snodata4/west/usr/local
  --enable-version-specific-runtime-libs Thread model: single gcc version 3.0

You need to update environmental variable SNO_EXTERNAL_LIBRARIES defined in
$SNO_TOOLS/get_lhost_info.scr by appending:-

  -Wl,-rpath -Wl,$INSTALLATION/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0
  -lgcc_s -lstdc++



 
Go Back to the
Snoman Companion Top Page