This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: bug in bfd/dwarf2.c recently


I'll look into it more...it was a large C++ project from work I was converting 
to
using shared libraries...I had undefined externals, so did
	nm -l *.o
and cored...
	nm *.o
didn't have the problem...

2.16 runs fine.

Trying to find a non-prorietary project this occurs on...

Seems its happening all over the place...
I'm using fedora 3 with g++ 3.4.2 -- I built with the installed fedora3
binutils (so its not an assembler/linker problem) and it happened with
nm -l again (built with -g).

Marty Leisner


Alan Modra <amodra@bigpond.net.au> writes  on Fri, 09 Dec 2005 11:05:36 +1030
     > On Sun, Dec 04, 2005 at 09:34:10PM -0500, Marty Leisner wrote:
     > > gdb) p *each_func
     > > $3 = {prev_func = 0x9689680, caller_func = 0x0, caller_file = 0x0,
     > >   caller_line = 0, file = 0x0, line = 0, tag = 46, name = 0x0, arange 
= {
     > >     next = 0x0, low = 558, high = 1089}, sec = 0x0}
     > > 
     > > each_func->name was passed into strcmp, hence the core dump...
     > > 
     > > This seemed to fix the coredumping issue:
     > > 
     > > : leisner@dell3;rcsdiff -u dwarf2.c
     > > ===================================================================
     > > RCS file: dwarf2.c,v
     > > retrieving revision 1.1
     > > diff -u -r1.1 dwarf2.c
     > > --- dwarf2.c    2005/12/05 02:00:02     1.1
     > > +++ dwarf2.c    2005/12/05 02:12:04
     > > @@ -1465,6 +1465,7 @@
     > >            arange = arange->next)
     > >         {
     > >           if ((!each_func->sec || each_func->sec == sec)
     > > +              && each_func->name 
     > >               && addr >= arange->low
     > >               && addr < arange->high
     > >               && strcmp (name, each_func->name) == 0
     > 
     > I'm curious as to why the name was not set.  Presumably your dwarf2
     > debug info has a DW_TAG_subprogram, DW_TAG_entry_point or
     > DW_TAG_inlined_subroutine without either a DW_AT_name attribute or
     > DW_AT_abstract_origin (or the DW_AT_abstract_origin doesn't have a
     > name).  Can you find out what is going on?  Depending on what you find,
     > a more appropriate fix might be
     > 
     >      && (!each_func->name || strcmp (name, each_func->name) == 0)
     > 
     > -- 
     > Alan Modra
     > IBM OzLabs - Linux Technology Centre



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