suffix sensitivity bug in GDB.

Todd Whitesel
Thu Aug 5 16:52:00 GMT 1999

We just tracked down a problem reported by a customer who mixes C and Assembly
files in their program, and the object files were suffixed .obj instead of .o,
and this was causing GDB to interpret the debug info incorrectly.

4.17, 68k family, a.out. Apparently with a.out stabs the way we detect
the end of a file is by seeing a symbol from the next file; if it is
__gnu_compiled from a C file then it always works. But if it is an
assembly file, then the linker inserts a single symbol such as "asm/foo.obj"
in front of any symbols that came from foo.obj. GDB's code to detect this
symbol depended on the suffix .o, and missed it.

The resulting failure was that the entire assembly file appeared to be part
of the last source line of the C file immediately before it in the link map,
so entering the assembly code via GDB meant you got confusing C source info
instead of 'no current source file'.

I eyeballed devo from late June and it appears to still exhibit this problem.

Has anyone else run into stuff like this, and are there cleaner fixes than a
"does this suffix look like an object file" function?

(Other than migrating to ELF, of course...)

Todd Whitesel
toddpw @

More information about the Gdb mailing list