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 PE/COFF port and parsing ?


Thanks for the Cc.  I am not on the list.

On 20 May 2003, David Carlton wrote:

> On Tue, 20 May 2003 16:14:32 -0500 (CDT), Brian Ford <ford@vss.fsi.com> said:
>
> > I'm still slowly trying to add DWARF2 support for PE/COFF targets.  I have
> > the following problem that confuses me and I was hoping for some expert
> > guidance about how to proceed.  gdb's symbol table code is completely
> > foreign to me.
>
> > If I load an executable into gdb that contains one object file with DWARF2
> > information (all the rest stabs), I get a segfault here:
>
> > 1431              if (!do_linear_search
> > 1432                  && (SYMBOL_LANGUAGE (*center) == language_java))
> > 1433                {
> > 1434                  do_linear_search = 1;
> > 1435                }
>
> The above code really should be deleted from the function in question,
> but never mind that; at least it's being a useful canary in the coal
> mine.
>
> > (gdb) p *center
> > $1 = (struct partial_symbol *) 0x20
>
> That's bad: 0x20 doesn't look like an address.  So the partial symbol
> table in question is screwed up.  Unfortunately, by the time you hit
> this bug, we've long since built the partial symbol tables.
>
Yup.  I know.

> For an example of building a partial symbol table, see
> dwarf2read.c:dwarf2_build_psymtabs_hard.  It gets created with
> start_psymtab_common, then some fields get set, then a function gets
> called (scan_partial_symbols, in this case) that eventually translates
> into a bunch of calls to add_psymbol_to_list to add the actual partial
> symbols, then the number of global and static symbols get set, then
> sort_pst_symbols gets called.  From your symptoms, maybe the number of
> global and/or static symbols got set wrong (or not at all) somewhere.
>
Thanks for the road map.  That was a good portion of what I was looking
for.  I'll have to trace down the chain.  Your assumption of what the
problem is sounds pretty good to me.

> What does "p *pst" say?  Unfortunately, the bug may have occurred when
> another psymtab was being generated: all the psymtabs within one
> objfile share one data structure, so an error when generating one
> psymtab may corrupt another psymtab's data.  (Sigh.  Partial symbol
> tables are a mess.)
>
(gdb) p *pst
Cannot access memory at address 0x0
(gdb) p pst
$1 = (struct partial_symtab *) 0x0

> If this doesn't help, maybe you could give some more details about
> exactly how you've been tinkering with the readers.
>
Actually, I haven't.  The tinkering I have done is in binutils to get
valid DWARF2 objects and let bfd know that PE/COFF can produce them.  gdb
is current cvs.  I have more tinkering to go, but the objects and
executables should be valid.  libdwarf and dwarfdump have no trouble
parsing them.

Thanks for the help and let me know if you think of anything to add.  I'll
try to start the chase in the psymtab building now that I have a very
fuzzy road map.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444


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