Re: SECT_OFF_DATA problems

[Todd Whitesel <toddpw at windriver dot com>]

> 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.

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.

> 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).

> [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?

-- 
Todd Whitesel
toddpw @ windriver.com