This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: SECT_OFF_DATA problems
Todd Whitesel writes:
> > I don't understand how this could have worked, really.
>
> I don't think it _ever_ worked. It only looked like it worked because
> the few people actually trying to use that machinery were vxWorks users,
> and WRS had hacks that made it mostly work. However there are fundamental
> problems with stabs, like identical stabs info for globals that are
> const and non-const, so you can't tell who is in RODATA and who isn't.
>
That's my impression. It doesn't look like it could ever have worked.
> It is good that Linux kernel module debugging has finally flushed this
> issue out into the open. My final solution involved using BFD to do the
> relocation work on the object file, and then convince the rest of GDB
> that no more offsets needed to be added. Unfortunately there are parts
> of GDB that expect to use the 'section_offsets' to find the addresses
> of things as well, so I had to audit every use and figure out if it was
> something that was linker relocated, or GDB relocated. It was nasty.
> Hopefully a cleaner method can be found to completely do away with this.
>
Yuck.
> > So my question is, what should gdb do with the SECT_OFF_* in case the
> > corresponding section is not found?
>
> IMHO most code using SECT_OFF_* is fundamentally incorrect because it
> assumes a classic program memory map. But if it's legitimate, then we
> should either track down the section or give an error (and rewrite the
> code that triggered it).
>
That's kind of what's happening now. internal_error is called whenever
we reference the index for a non existent section. But we need to do
better than that of course.
> > [Right now the first place where the SECT_OFF_DATA macro is used is in
> > record_minimal_symbol_and_info(), in elfread.c. GDB classifies minimal
> > symbols into 3 classes: text, bss, data and uses the corresponding
> > offsets.]
>
> Um, isn't it simply bogus to crunch things into text/data/bss when your
> OMF is COFF or ELF and can have all sorts of weird sections like .rodata
> and .sbss2 and so on?
>
Yes, that's my point. If we use the offset for the section where each
symbol is, then SECT_OFF_* become useless, I would say. The only
tproblem I can see is that the section for a symbol may not be known
at all the points where we use the symbol. But we could store the
section number in the symbol structure, right?
Elena
> --
> Todd Whitesel
> toddpw @ windriver.com