Node:Included source,
Next:Static vars,
Previous:C++ classes in GDB,
Up:Debugging
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 #include
d
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
:
f2c
with the -g
option:
f2c -g myprog.f
gcc
with the -g
option:
gcc -g myprog.c -o myprog.exe -lf2c -lm
copy myprog.f myprog.c
gdb myprog.exe