This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: dwarf2 symtab bfd_section corrupt?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sun, 2 Mar 2003 23:47:21 -0500
- Subject: Re: dwarf2 symtab bfd_section corrupt?
- References: <3E624542.1000108@redhat.com>
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