This is the mail archive of the gdb@sources.redhat.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]
Other format: [Raw text]

Re: dwarf2 symtab bfd_section corrupt?


On Sun, Mar 02, 2003 at 12:54:10PM -0500, Andrew Cagney wrote:
> Hello,
> 
> Both the symtab and psymtab objects contain the common entry `asection 
> *bfd_section'.  One field of the BFD section is it's `struct bfd *owner' 
> - the object file that contains the section.
> 
> The new dwarf2loc stuff extends the symtab object adding a `struct 
> objfile *objfile' field.  An objfile contains the field `struct bfd *obfd'.
> 
> Hmm, looks like redundant information.  Why not just point the 
> symtab/psymtab at the obj_section?
> 
> The attached patch adds an assert to check the theory out.  It fails. 
> The bfd_section ends up pointing at the file "libc.so"!
> 
> Andrew

Well now, isn't _that_ interesting.  Here's the problem:
symtab.c:fixup_section sets the BFD_SECTION of a symbol based on doing
a minsym lookup, which assumes a 1-1 correspondence.  The first crash I
see in the testsuite is for a variable named f3, which happens to occur
in the debug info for libm.  This is in call-rt-st.

Something's wrong here; f3 is really a stack local.  It shouldn't have
a SYMBOL_BFD_SECTION.  Even if it did we should be setting based on an
address->section mapping, not by a name-based minsym lookup, I think.
I have no idea how that would work with, say, overlays though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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