search

ykagan / google-breakpad

Automatically exported from code.google.com/p/google-breakpad
0 stars 0 forks source link

dumpsyms not able to extract ELF BuildID #589

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Install a package with normal, stripped ELF binary and -debuginfo package 
with the binary ".debug" file
2. Run "objdump -s" on stripped binary, observe the build-id section.
3. Run "objdump -s" on the .debug file, observe identical build-id section.
4. Run dumpsyms on the original binary, observe normal output
3. Run dumpsyms on the .debug file, observe output is "unable to generate file 
identifier" with no symbols

What is the expected output? What do you see instead?
I would expect that the ".debug" file would generate the same symbols output as 
the original binary

What version of the product are you using? On what operating system?
google-breakpad rev. 1234

Please provide any additional information below.
I checked in a debugger under "file_id.cc" function 
"ElfClassBuildIDNoteIdentifier" and it seems like the 64-bit section iterator 
does not correspond with the output from objdump. The "note_header->n_type" 
values are wildly different.

Original issue reported on code.google.com by brian.si...@gmail.com on 9 May 2014 at 2:46

GoogleCodeExporter commented 9 years ago 
FYI this occurs on the executables (i.e. under /usr/bin) on my Fedora system 
but does not occur for the libraries (i.e. under /usr/lib64) split in a similar 
way between stripped binary and separate .debug file.

My system is x86_64 architecture.

Original comment by brian.si...@gmail.com on 9 May 2014 at 2:55

GoogleCodeExporter commented 9 years ago 
You should either run:
dump_syms foo_unstripped
or
dump_syms foo_stripped /path/containing_foo_dot_debug/

It sounds like you are running /path/containing_foo_dot_debug/foo.debug. That 
isn't going to work right because foo.debug has an empty .eh_frame section 
(type SHT_NOBITS instead of SHT_PROGBITS) so dump_syms cannot generate the CFI 
data.

Beyond that, it should still work and dump out some info sans CFI data. I built 
a 64-bit dump_syms at r1327 and it work fine here when I run dump_syms 
foo.debug. I don't get the "unable to generate file identifier" error.

Original comment by thestig@chromium.org on 10 May 2014 at 12:19