Closed GoogleCodeExporter closed 9 years ago
Presumably it would be more interesting to find out what is causing the symbol
dumping code to produce that FUNC record without a name.
Original comment by ted.mielczarek
on 7 Mar 2011 at 1:13
Well, yes. But I know nothing about DWARF ...
It seems that the function having problems is catgets :
# grep catgets */*
BD56F36E5BCC098768E2E1905DCB65590/libc-2.5.so.sym:FILE 393 catgets.c
E383BDB3936E8FB51D132700084794530/libc-2.5.so.sym:FILE 393 catgets.c
# nm /lib/libc-2.5.so | grep catgets
00027620 T catgets
The source for catgets.c can be found here :
http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=catgets/catgets.c;hb=88cc6
1e84e8e75e6e91b1a2e51147aeb63712ff8
Nothing special in the definition nor the declaration ...
Original comment by tonton1...@gmail.com
on 7 Mar 2011 at 1:41
If I could get a copy of the given libc-2.5.so, that would help me reproduce
this. GLIBC is GPL, so it should be fine to put up a copy for me somewhere.
Original comment by jimbla...@gmail.com
on 8 Mar 2011 at 2:12
$ dump_syms lib/libc-2.5.so usr/lib/debug/lib
Original comment by tonton1...@gmail.com
on 8 Mar 2011 at 2:30
Attachments:
Thanks; I can reproduce this now. The DWARF information is incorrect ---
perhaps there is a bug in the linker or compiler? --- but dump_syms should
never generate invalid symbol files, so there's still a breakpad bug.
The bad FUNC line generated looks like this, as you say:
FUNC 27620 ab 0
The DWARF entry for that function looks like this:
<1><348ee>: Abbrev Number: 17 (DW_TAG_subprogram)
<348ef> DW_AT_sibling : <0x3496c>
<348f3> DW_AT_external : 1
<348f4> DW_AT_name : (indirect string, offset: 0x5ae0):
<348f8> DW_AT_decl_file : 1
<348f9> DW_AT_decl_line : 86
<348fa> DW_AT_prototyped : 1
<348fb> DW_AT_type : <0x34761>
<348ff> DW_AT_low_pc : 0x27620
<34903> DW_AT_high_pc : 0x276cb
<34907> DW_AT_frame_base : 0x12564 (location list)
So you can see that the debug information indeed points to a null string as the
name of the function. That specific portion of the .debug_str section looks
like this:
...
[ 5aa0] catclose
[ 5aa9] name_ptr
[ 5ab2] /usr/src/debug/glibc-2.5-20061008T1257/catgets
[ 5ae1] atgets
[ 5ae8] file_size
[ 5af2] plane_depth
...
The DW_AT_name attribute is weird, because it's pointing to the null character
at the end of the 5ab2 entry (the filename), not at the next entry --- and the
next entry should probably be "catgets", not "atgets". So I think this was
generated by a buggy linker, or some post-processing tool botched something.
Working on a fix.
Original comment by jimbla...@gmail.com
on 8 Mar 2011 at 8:08
Posted patch:
http://breakpad.appspot.com/270001
Original comment by jimbla...@gmail.com
on 8 Mar 2011 at 9:48
Original comment by jimbla...@gmail.com
on 8 Mar 2011 at 9:48
Should be fixed in r779.
Original comment by jimbla...@gmail.com
on 11 Mar 2011 at 10:17
In r779, at the last moment, I added a default call count expectation for
the UnnamedFunction warning to the CUFixtureBase constructor, but didn't
re-run the tests.
The patch here adjusts all affected tests:
http://breakpad.appspot.com/272001
Original comment by jimbla...@gmail.com
on 14 Mar 2011 at 5:08
Tests fixed in r782.
Original comment by jimbla...@gmail.com
on 15 Mar 2011 at 7:24
Original issue reported on code.google.com by
tonton1...@gmail.com
on 13 Jan 2011 at 5:41Attachments: