[an error occurred while processing this directive] Node:Included source, Next:, Previous:C++ classes in GDB, Up:Debugging

12.6 GDB cannot list source that was #include'd

Q: My source file #include's another source file, but I cannot set a breakpoint in that included code, because GDB says there is no such line, or no such source file....

Q: I cannot debug code produced by Flex, or Bison, or F2C, because GDB somehow messes up all the source file and line number info!

Q: Why can't I step with a debugger into an inline function defined in a header file?

Q: Why can't I trace into a function defined in an #included source file?

A: This is a genuine limitation of the COFF format used by DJGPP. It can only handle a single source file for a given object file. It does include correct line numbers, but the name of the source file is wrong, so setting breakpoints in such files or tracing into functions defined in such files just doesn't work. Using stabs debugging info (see the previous section) doesn't have this limitation, so upgrade to GCC 2.8.0 or later and recompile your program with the -gstabs+ switch.

For source files that include other source files, you can work around this even with COFF debugging, by just inserting the included source with your editor while you debug the program. For code produced by other programs, like F2C or Bison, Duncan Murdoch suggests a work-around: to copy the original source file (.y, .f, etc.) over the generated C file. For example, here's how you should go about debugging a Fortran program myprog.f using GCC, F2C and GDB:

  1. Run f2c with the -g option:
     f2c -g myprog.f
    
  2. Compile using gcc with the -g option:
     gcc -g myprog.c -o myprog.exe -lf2c -lm
    
  3. Copy the original Fortran source over the generated C:
     copy myprog.f myprog.c
    
  4. Debug with GDB:
     gdb myprog.exe
    


[an error occurred while processing this directive]