This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]