Problem with stabs debug info in new object format

Hello everyone,


This question is not exactly about code generation but rather about
object format management.


I have designed an object format for a project I'm working on (I
didn't know of one that allowed an arbitrary number of sections with
names and a bunch of attributes, allowed for having code and data for
several architectures in one file, had provision for 'resources'
(icons, etc.), could contain runtime relocation information, and still
could be read very simply :). So far, everything works well - I added
full support for it in GNU BFD and specifically in the binutils and
gdb source trees.


I use stabs as generated by gcc with -gstabs for debug information,
notably line numbers. After writing the proper support in bfd, tools
like 'nm' report the correct line number info in the final executable,
so I assume the linking process and my bfd back-end are correct about
this.


However, although I added that bfd back-end to gdb and added specific
gdb support for reading psymtabs, and I can debug a running program
just fine, with the symbols mapped at the right addresses in all
sections, gdb gets the line number information wrong. Apparently, it
thinks that all source files that were involved in one executable,
start at the same address, while their addresses got offset by the
linker when it concatenates and links them.


I've seen somewhere that stabs information is relative to the start of
the _source file_ they appear in, so that would make sense: somehow
binutils retrieve the start address of a particular source file in the
final executable, and add the offset in stabs, to form the correct
address for a source line; while gdb doesn't find the start address
and just uses the offset, making all sources overlap and produces
incorrect line info.


I have been looking for a while in other format readers, in gdb
internal documentation and other places before asking here; can anyone
confirm that I've understood the problem right at least, and possibly
explain how to work around it in gdb ?


Thanks a lot, and sorry if this is halfway off-topic on a newsgroup
about code generation..


--
Emmanuel

Return to the comp.compilers page.
Search the comp.compilers archives again.