search

Cloosen-Calories / google-breakpad

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

dump_syms 64bit not work #381

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
At first in src/tools/linux/dump_syms/Makefile hard code -m32

If remove -m32, make OK. execute result:
STACK CFI 15b1 .cfa: $rsp 16 +
STACK CFI 15b7 .cfa: $rsp 24 +
STACK CFI 15be $rbp: .cfa -16 + ^ $rbx: .cfa -24 + ^ .cfa: $rsp 176 +
STACK CFI INIT 2c40 bb .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1690 15 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1694 .cfa: $rsp 16 +
STACK CFI INIT 16b0 27 .cfa: $rsp 8 + .ra: .cfa -8 + ^

It must be printf format error, is right?

Original issue reported on code.google.com by ken.s...@gmail.com on 2 Apr 2010 at 9:46

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
unit test log:

[  FAILED  ] 3 tests, listed below:
[  FAILED  ] CFIInsn.DW_CFA_def_cfa
[  FAILED  ] CFIInsn.DW_CFA_remember_and_restore_stateCFA
[  FAILED  ] CFIInsn.SkipFDE

os: red hat Linux 2.6.18 x86_64
in src/tools/linux/dump_syms/Makefile remove -m32

Original comment by ken.s...@gmail.com on 2 Apr 2010 at 10:17

GoogleCodeExporter commented 9 years ago 
I'll look at this.

Original comment by jimbla...@gmail.com on 5 Apr 2010 at 5:38

GoogleCodeExporter commented 9 years ago 
I'll look at this.

Original comment by jimbla...@gmail.com on 5 Apr 2010 at 5:38

GoogleCodeExporter commented 9 years ago 
I can reproduce this problem.

Original comment by jimbla...@gmail.com on 5 Apr 2010 at 5:54

GoogleCodeExporter commented 9 years ago 
The patch here should fix the test failures; could you verify this?
http://breakpad.appspot.com/97001

What is incorrect about the 'STACK CFI' records that you posted?

Original comment by jimbla...@gmail.com on 5 Apr 2010 at 7:22

GoogleCodeExporter commented 9 years ago 
>> The patch here should fix the test failures; could you verify this?
Yes, the unit test success with your patch.

>> What is incorrect about the 'STACK CFI' records that you posted?
I cat a symbols file(result of dump_syms)
It's different from 32bit.

Process a dump file still failed.

Original comment by ken.s...@gmail.com on 6 Apr 2010 at 1:11

GoogleCodeExporter commented 9 years ago 
The dumper uses the architecture given in the file's ELF header (see the 
'Machine:'
line in the output from 'readelf -h FILENAME') to decide what register names to 
use
in the 'STACK CFI' records.  '$rsp', '$rbx', and '$rbp' are names of registers 
on the
x86_64, so I would assume that you are dumping an x86_64 (-m64) executable when 
you
receive that output.  That looks like correct output for an x86_64 executable.

Note that, on Linux, the dumper must itself be compiled as a 32-bit program in 
order
to dump x86 (-m32) programs, and the dumper must be compiled as a 64-bit 
program in
order to dump x86_64 (-m64) programs. The Linux dumper cannot be used with
architectures of a different word size.  However, a 32-bit dumper can dump any 
32-bit
architecture, so an x86 dumper can dump an ARM executable.

If this doesn't explain the behavior you're seeing, could you attach 1) the
executable you're dumping, 2) the output you're getting from running dump_syms 
on
that executable, and 3) a minidump produced by that executable that the 
processor is
unable to get a stack trace from?

Original comment by jimbla...@gmail.com on 6 Apr 2010 at 3:48

GoogleCodeExporter commented 9 years ago 
Thanks a lot your patient.

1) I build dump_syms with the Makefile removed '-m32', so it should be ELF64.
2) The executable also be 64bit. (source attached bp_test.cc)
  maked with
  g++ -gstabs+ -O2 bp_test.cc libbreakpad.a -o bp_test

3) dump_syms result attached bp_test.sym.64bit

4) minidump_stackwalk is also 64bit. process result:
2010-04-06 12:05:46: minidump_processor.cc:238: INFO: Processing minidump in 
file
4ecf7c2f-6f67-7d26-528dcfdf-2e414e5f.dmp
2010-04-06 12:05:46: minidump.cc:3494: INFO: Minidump opened minidump
4ecf7c2f-6f67-7d26-528dcfdf-2e414e5f.dmp
2010-04-06 12:05:46: minidump.cc:3539: INFO: Minidump not byte-swapping minidump
2010-04-06 12:05:46: minidump.cc:3896: INFO: GetStream: type 1197932545 not 
present
2010-04-06 12:05:46: minidump.cc:3896: INFO: GetStream: type 1197932546 not 
present
2010-04-06 12:05:46: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /data/xce/g/google-breakpad-read-only/src/client/linux/bp_test
2010-04-06 12:05:46: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/ld-2.5.so
2010-04-06 12:05:46: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/libc-2.5.so
2010-04-06 12:05:46: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/libm-2.5.so
2010-04-06 12:05:46: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /usr/lib64/libstdc++.so.6.0.8
2010-04-06 12:05:46: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/libgcc_s-4.1.2-20080825.so.1
2010-04-06 12:05:46: minidump_processor.cc:106: INFO: Minidump
4ecf7c2f-6f67-7d26-528dcfdf-2e414e5f.dmp has CPU info, OS info, no Breakpad 
info,
exception, module list, thread list, no dump thread, and requesting thread
2010-04-06 12:05:46: minidump_processor.cc:140: INFO: Looking at thread
4ecf7c2f-6f67-7d26-528dcfdf-2e414e5f.dmp:0/1 id 0x7a7b
2010-04-06 12:05:46: minidump.cc:307: INFO: MinidumpContext: looks like AMD64 
context
2010-04-06 12:05:46: minidump.cc:307: INFO: MinidumpContext: looks like AMD64 
context
2010-04-06 12:05:46: simple_symbol_supplier.cc:149: INFO: No symbol file at
symbols//bp_test/6C5C3A412CEAA35BB71CC412E65C70140/bp_test.sym
2010-04-06 12:05:46: minidump_processor.cc:232: INFO: Processed
4ecf7c2f-6f67-7d26-528dcfdf-2e414e5f.dmp
2010-04-06 12:05:46: minidump.cc:3466: INFO: Minidump closing minidump
Operating system: Linux
                  0.0.0 Linux 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64
CPU: amd64
     family 6 model 23 stepping 6
     1 CPU

Crash reason:  SIGSEGV
Crash address: 0x0

Thread 0 (crashed)
 0  bp_test + 0x1520
    rbx = 0x198f2010   r12 = 0x00000000   r13 = 0x69106ae0   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401520   rsp = 0x69106950   rbp = 0x00000000

Loaded modules:
0x00400000 - 0x0040cfff  bp_test  ???  (main)
0x300cc00000 - 0x300cc1bfff  ld-2.5.so  ???
0x300d000000 - 0x300d14bfff  libc-2.5.so  ???
0x300d800000 - 0x300d881fff  libm-2.5.so  ???
0x300ec00000 - 0x300ece5fff  libstdc++.so.6.0.8  ???
0x300f400000 - 0x300f40cfff  libgcc_s-4.1.2-20080825.so.1  ???

Original comment by ken.s...@gmail.com on 6 Apr 2010 at 4:07

Attachments:

GoogleCodeExporter commented 9 years ago 
The output from minidump_stackwalk says:

2010-04-06 12:05:46: simple_symbol_supplier.cc:149: INFO: No symbol file at
symbols//bp_test/6C5C3A412CEAA35BB71CC412E65C70140/bp_test.sym

That suggests that it was unable to find your symbol file.  This would certainly
result in a one-frame stack trace.  Could you fix this and try again?

Original comment by jimbla...@gmail.com on 6 Apr 2010 at 4:28

GoogleCodeExporter commented 9 years ago 
Much Thanks.

I forgot the .sym extension. After rename symbols file, the process result:

Crash reason:  SIGSEGV
Crash address: 0x0

Thread 0 (crashed)
 0  bp_test + 0x1520
    rbx = 0x0530f010   r12 = 0x00000000   r13 = 0x2590f300   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401520   rsp = 0x2590f170   rbp = 0x00000000
 1  bp_test + 0x1534
    rbx = 0x0530f010   r12 = 0x00000000   r13 = 0x2590f300   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401535   rsp = 0x2590f178   rbp = 0x00000000
 2  bp_test + 0x160a
    rbx = 0x0530f010   r12 = 0x00000000   r13 = 0x2590f300   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x0040160b   rsp = 0x2590f180   rbp = 0x00000000
 3  libc-2.5.so + 0x1d973
    rbx = 0x0ce1bbc0   r12 = 0x00000000   r13 = 0x2590f300   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x0d01d974   rsp = 0x2590f230   rbp = 0x00000000

the crash function name, source code line are not showed.

Any suggestion?

Original comment by ken.s...@gmail.com on 6 Apr 2010 at 4:32

GoogleCodeExporter commented 9 years ago 
I'm glad it's producing a stack trace now.

I noticed that your .sym file doesn't have any FILE, FUNC, or line records in 
it at
all --- only STACK CFI records. This would be consistent with an executable 
compiled
without -g, as all x86_64 executables are required to have .eh_frame sections.

Was the executable you dumped compiled with -g?  Does it have a .debug_info or 
.stabs
section?  (The command 'readelf -S FILENAME' lists an ELF file's sections.)

Original comment by jimbla...@gmail.com on 6 Apr 2010 at 4:42

GoogleCodeExporter commented 9 years ago 
1) I compiled it with -g, process result:
2010-04-06 13:31:56: minidump_processor.cc:238: INFO: Processing minidump in 
file
082ced22-0348-3577-1b271c50-4ea08f8b.dmp
2010-04-06 13:31:56: minidump.cc:3494: INFO: Minidump opened minidump
082ced22-0348-3577-1b271c50-4ea08f8b.dmp
2010-04-06 13:31:56: minidump.cc:3539: INFO: Minidump not byte-swapping minidump
2010-04-06 13:31:56: minidump.cc:3896: INFO: GetStream: type 1197932545 not 
present
2010-04-06 13:31:56: minidump.cc:3896: INFO: GetStream: type 1197932546 not 
present
2010-04-06 13:31:56: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /data/xce/g/google-breakpad-read-only/src/client/linux/bp_test
2010-04-06 13:31:56: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/ld-2.5.so
2010-04-06 13:31:56: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/libc-2.5.so
2010-04-06 13:31:56: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/libm-2.5.so
2010-04-06 13:31:56: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /usr/lib64/libstdc++.so.6.0.8
2010-04-06 13:31:56: minidump.cc:1942: INFO: MinidumpModule could not determine
version for /lib64/libgcc_s-4.1.2-20080825.so.1
2010-04-06 13:31:56: minidump_processor.cc:106: INFO: Minidump
082ced22-0348-3577-1b271c50-4ea08f8b.dmp has CPU info, OS info, no Breakpad 
info,
exception, module list, thread list, no dump thread, and requesting thread
2010-04-06 13:31:56: minidump_processor.cc:140: INFO: Looking at thread
082ced22-0348-3577-1b271c50-4ea08f8b.dmp:0/1 id 0x14a2
2010-04-06 13:31:56: minidump.cc:307: INFO: MinidumpContext: looks like AMD64 
context
2010-04-06 13:31:56: minidump.cc:307: INFO: MinidumpContext: looks like AMD64 
context
2010-04-06 13:31:56: basic_source_line_resolver.cc:263: INFO: Loading symbols 
for
module /data/xce/g/google-breakpad-read-only/src/client/linux/bp_test from 
buffer
2010-04-06 13:31:56: simple_symbol_supplier.cc:149: INFO: No symbol file at
symbols/libc-2.5.so/D443CAE1597E3BDA60ECDADB84D183290/libc-2.5.so.sym
2010-04-06 13:31:56: minidump_processor.cc:232: INFO: Processed
082ced22-0348-3577-1b271c50-4ea08f8b.dmp
2010-04-06 13:31:56: minidump.cc:3466: INFO: Minidump closing minidump
Operating system: Linux
                  0.0.0 Linux 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64
CPU: amd64
     family 6 model 23 stepping 6
     1 CPU

Crash reason:  SIGSEGV
Crash address: 0x0

Thread 0 (crashed)
 0  bp_test + 0x1520
    rbx = 0x08dfb010   r12 = 0x00000000   r13 = 0x465d8000   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401520   rsp = 0x465d7e70   rbp = 0x00000000
 1  bp_test + 0x1534
    rbx = 0x08dfb010   r12 = 0x00000000   r13 = 0x465d8000   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401535   rsp = 0x465d7e78   rbp = 0x00000000
 2  bp_test + 0x160a
    rbx = 0x08dfb010   r12 = 0x00000000   r13 = 0x465d8000   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x0040160b   rsp = 0x465d7e80   rbp = 0x00000000
 3  libc-2.5.so + 0x1d973
    rbx = 0x0ce1bbc0   r12 = 0x00000000   r13 = 0x465d8000   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x0d01d974   rsp = 0x465d7f30   rbp = 0x00000000

Loaded modules:
0x00400000 - 0x0040cfff  bp_test  ???  (main)
0x300cc00000 - 0x300cc1bfff  ld-2.5.so  ???
0x300d000000 - 0x300d14bfff  libc-2.5.so  ???
0x300d800000 - 0x300d881fff  libm-2.5.so  ???
0x300ec00000 - 0x300ece5fff  libstdc++.so.6.0.8  ???
0x300f400000 - 0x300f40cfff  libgcc_s-4.1.2-20080825.so.1  ???

the crash function name, source code line are still not showed dispirited.

Build command:
g++ -g -gstabs+ -O2 -I../.. bp_test.cc -c
g++ bp_test.o libbreakpad.a -o bp_test

I notice:
2010-04-06 13:34:55: minidump.cc:307: INFO: MinidumpContext: looks like AMD64 
context
2010-04-06 13:34:55: minidump.cc:307: INFO: MinidumpContext: looks like AMD64 
context

Is it a little strange?   The cpuinfo below:
$cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 23
model name  : Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz
....

2) I process in my Ubuntu(32bit) without -g, the result is right with function 
name,
source code line. The result like:

Thread 0 (crashed)
 0  bp_test!main [bp_test.cc : 15 + 0x0]
    eip = 0x08049535   esp = 0xbfe89fd0   ebp = 0xbfe8a058   ebx = 0xbfe8a038
    esi = 0xbfe89ff8   edi = 0x00000000   eax = 0x09918008   ecx = 0x00000000
    edx = 0x00000001   efl = 0x00010202

Is -gstabs+ enough?

The make command:
g++ -gstabs+ -O2 -I../.. bp_test.cc -c
g++ bp_test.o libbreakpad.a -o bp_test

Thanks a lot...

Original comment by ken.s...@gmail.com on 6 Apr 2010 at 5:43

GoogleCodeExporter commented 9 years ago 
When you compiled with -g, and then dumped the symbols again, did the new .sym 
file
include lines beginning with "FILE" and "FUNC"?

Original comment by jimbla...@gmail.com on 6 Apr 2010 at 4:45

GoogleCodeExporter commented 9 years ago 
No, there is not any line beginning with FILE or FUNC

Original comment by ken.s...@gmail.com on 7 Apr 2010 at 5:45

GoogleCodeExporter commented 9 years ago 
If you could, please attach a terminal transcript showing the following steps 
(it's
fine if it's large):

1) compiling dump_syms
2) compiling your test program
3) running dump_syms on your test program, with output to stdout

Original comment by jimbla...@gmail.com on 7 Apr 2010 at 6:01

GoogleCodeExporter commented 9 years ago 
That is, please do a 'make clean' before the dump_syms build.

Original comment by jimbla...@gmail.com on 7 Apr 2010 at 6:04

GoogleCodeExporter commented 9 years ago 
## 1) make clean breakpad
[xce@TJSJHL219-47 google-breakpad-read-only]$ pwd
/data/xce/g/google-breakpad-read-only

## 2) make dump dump_syms
[xce@TJSJHL219-47 google-breakpad-read-only]$ cd src/tools/linux/dump_syms/
[xce@TJSJHL219-47 dump_syms]$ make clean
[xce@TJSJHL219-47 dump_syms]$ make

## 3) make test programm, and execute dump_syms
[xce@TJSJHL219-47 dump_syms]$ cd ../../../client/linux/

[xce@TJSJHL219-47 linux]$ g++ -g -gstabs+ -O2 -I../.. bp_test.cc -c
[xce@TJSJHL219-47 linux]$ g++ -g bp_test.o libbreakpad.a -o bp_test

[xce@TJSJHL219-47 linux]$ ../../tools/linux/dump_syms/dump_syms bp_test
symbol 771: name offset outside the string section
symbol 771: name offset outside the string section
symbol 947: name offset outside the string section
symbol 947: name offset outside the string section
symbol 2706: name offset outside the string section
symbol 2706: name offset outside the string section
symbol 4610: name offset outside the string section
symbol 4610: name offset outside the string section
symbol 5093: name offset outside the string section
symbol 5093: name offset outside the string section
symbol 5794: name offset outside the string section
symbol 5794: name offset outside the string section
symbol 5836: name offset outside the string section
symbol 5836: name offset outside the string section
symbol 6479: name offset outside the string section
symbol 6479: name offset outside the string section
symbol 7028: name offset outside the string section
symbol 7028: name offset outside the string section
symbol 7093: name offset outside the string section
symbol 7093: name offset outside the string section
MODULE Linux x86_64 6C5C3A412CEAA35BB71CC412E65C70140 bp_test
STACK CFI INIT 1520 9 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1530 7 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1540 5 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1550 5 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1560 5 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1570 5 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1580 5 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1590 20 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1594 .cfa: $rsp 16 +
STACK CFI INIT 15b0 de .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 15b1 .cfa: $rsp 16 +
STACK CFI 15b7 .cfa: $rsp 24 +
STACK CFI 15be $rbp: .cfa -16 + ^ $rbx: .cfa -24 + ^ .cfa: $rsp 176 +
STACK CFI INIT 2c40 bb .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 1690 15 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1694 .cfa: $rsp 16 +
STACK CFI INIT 16b0 27 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 16b4 .cfa: $rsp 16 +
STACK CFI INIT 2d00 2a .cfa: $rsp 8 + .ra: .cfa -8 + ^

[.... it is too long ...]

STACK CFI INIT a480 2 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT a490 8b .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI a49a $r12: .cfa -40 + ^ $r13: .cfa -32 + ^
STACK CFI a4ab $r14: .cfa -24 + ^ $r15: .cfa -16 + ^
STACK CFI a4bc $rbp: .cfa -48 + ^ $rbx: .cfa -56 + ^ .cfa: $rsp 64 +

Original comment by ken.s...@gmail.com on 8 Apr 2010 at 2:27

GoogleCodeExporter commented 9 years ago 
There's no reason to use -gstabs+ since the Linux DWARF support landed in 
February. 
If you compile bp_test without -gstabs+, with -g only, does that help?

Original comment by jimbla...@gmail.com on 8 Apr 2010 at 3:26

GoogleCodeExporter commented 9 years ago 
Also, what SVN revision of breakpad are you using?

Original comment by jimbla...@gmail.com on 8 Apr 2010 at 7:05

GoogleCodeExporter commented 9 years ago 
Revision: 564

with patch http://breakpad.appspot.com/97001

Original comment by ken.s...@gmail.com on 8 Apr 2010 at 9:03

GoogleCodeExporter commented 9 years ago 
>>If you compile bp_test without -gstabs+, with -g only, does that help?
Yes it help. Thanks u are my god!

Thread 0 (crashed)
 0  bp_test!bar [bp_test.cc : 15 + 0x0]
    rbx = 0x13c62010   r12 = 0x00000000   r13 = 0xd2c30660   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401520   rsp = 0xd2c304d0   rbp = 0x00000000
 1  bp_test!foo [bp_test.cc : 19 + 0x4]
    rbx = 0x13c62010   r12 = 0x00000000   r13 = 0xd2c30660   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x00401535   rsp = 0xd2c304d8   rbp = 0x00000000
 2  bp_test!main [bp_test.cc : 49 + 0x4]
    rbx = 0x13c62010   r12 = 0x00000000   r13 = 0xd2c30660   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x0040160b   rsp = 0xd2c304e0   rbp = 0x00000000
 3  libc-2.5.so + 0x1d973
    rbx = 0x0ce1bbc0   r12 = 0x00000000   r13 = 0xd2c30660   r14 = 0x00000000
    r15 = 0x00000000   rip = 0x0d01d974   rsp = 0xd2c30590   rbp = 0x00000000

Original comment by ken.s...@gmail.com on 8 Apr 2010 at 9:04

GoogleCodeExporter commented 9 years ago 
I've gotten access to an x86_64 Linux machine, and can confirm that dump_syms
produces no FILE/FUNC/line records for programs compiled with -gstabs+.

Original comment by jimbla...@gmail.com on 8 Apr 2010 at 3:48

GoogleCodeExporter commented 9 years ago 
Glad to hear that helped.  Since February, you shouldn't need to use STABS with
breakpad at all.

Original comment by jimbla...@gmail.com on 8 Apr 2010 at 4:14

GoogleCodeExporter commented 9 years ago 
I think my upcoming patches will fix this:
http://hg.mozilla.org/users/jblandy_mozilla.com/breakpad-mq/

The problem is that 'struct nlist', as declared in /usr/include/a.out.h, 
declares its
'n_value' field as an 'unsigned long', which is 32 bits long on x86, but 64 
bits long
on x86_64.  However, entries in .stabs sections in x86_64 executables have 
32-bit
values.  Since 'struct nlist' and the data actually in the file don't match,
Breakpad's dump_syms misinterprets the contents of the .stabs section.  This is 
the
cause of the many "name offset outside the string section" messages.

In the patch queue linked above, abstract-stabs.patch changes the
google_breakpad::StabsReader class to use explicit sizes for all stabs entry 
fields,
rather than relying on the definition of 'struct nlist' from the system 
headers. 
However, that patch depends on the prior patches in the series being applied.

Original comment by jimbla...@gmail.com on 8 Apr 2010 at 4:24

GoogleCodeExporter commented 9 years ago 
I've confirmed that the patch queue mentioned above, applied up to
abstract-stabs.patch, fixes this problem:

$ cat hello.c
#include <stdio.h>

int main(int argc, char **argv) {
  printf("Hello, world!\n");
  return 0;
}
$ gcc -gstabs+ hello.c -o hello
$ (cd breakpad; hg qap)
move-test-assembler.patch
cfi-register-names.patch
dump-stabs-test-leak.patch
bytecursor.patch
abstract-stabs.patch
$ ./breakpad/src/tools/linux/dump_syms/dump_syms hello
MODULE Linux x86_64 C738B53E82EA974C1704C98D300A24F20 hello
FILE 0 hello.c
FUNC 364 20 0 main
364 f 3 0
373 a 4 0
37d 5 5 0
382 2 6 0
STACK CFI INIT 364 20 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 365 .cfa: $rsp 16 +
STACK CFI 368 $rbp: .cfa -16 + ^ .cfa: $rbp 16 +
STACK CFI INIT 390 2 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI INIT 3a0 89 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 3b1 $r12: .cfa -40 + ^ $rbp: .cfa -48 + ^
STACK CFI 3d0 .cfa: $rsp 64 +
STACK CFI 3d6 $r13: .cfa -32 + ^ $r14: .cfa -24 + ^ $r15: .cfa -16 + ^ $rbx: 
.cfa -56 + ^
$

Original comment by jimbla...@gmail.com on 8 Apr 2010 at 4:28

GoogleCodeExporter commented 9 years ago 
I learned a lot.

Thank you vvvvvery much.

Original comment by ken.s...@gmail.com on 9 Apr 2010 at 1:46

GoogleCodeExporter commented 9 years ago 
Thanks for the bug report --- it prompted me to straighten out those test 
failures on
x86_64, and now I know that a.out.h's struct nlist doesn't match the actual 
data's
format.

Original comment by jimbla...@gmail.com on 9 Apr 2010 at 4:43