This is a follow up to bug 10219. I have a slightly more complicated test case that works with ld but fails with gold. gcc -m32 -gstabs foo.c abcdefghijklmnopqrstuvwxyz/bar.c -o foo; dump_syms foo outputs: MODULE Linux x86 14CA077E2EEA0AD8414217ED5D9862B70 foo FILE 0 foo.c FILE 1 abcdefghijklmnopqrstuvwxyz/bar.c FUNC 3a4 30 0 main 3a4 11 5 0 3b5 c 6 0 3c1 5 7 0 3c6 5 8 0 3cb 9 9 0 FUNC 3d4 14 0 bar 3d4 6 4 1 3da c 5 1 3e6 2 6 1 gcc -m32 -gstabs foo.c abcdefghijklmnopqrstuvwxyz/bar.c -o foo -B/path/to/gold; dump_syms foo outputs: MODULE Linux x86 FE9F1B283112582FEBD35996C677C4160 foo FILE 0 foo.c FILE 1 foo.c FUNC 1e4 30 0 main 1e4 11 5 0 1f5 c 6 0 201 5 7 0 206 5 8 0 20b 9 9 0 FUNC 214 14 0 ijklmnopqrstuvwxyz/bar.c 214 6 4 1 21a c 5 1 226 2 6 1
Created attachment 4024 [details] test case
I finally took another look at this. The problem here is simply that dump_syms is incorrect. It only works if the stabs strings have been optimized into a single compilation unit. The GNU linker does that optimization by default, but gold does not (since very few people use stabs debugging these days). When there are multiple compilation units in the stabs data, a special stabs entry with a type of 0 gives the size of each unit. This is documented (briefly) here: http://sourceware.org/gdb/onlinedocs/stabs/Stab-Section- Basics.html#Stab-Section-Basics . I'll append a patch which fixes the google-breakpad problem.
Created attachment 4487 [details] google-breakpad patch This patch seems to fix google breakpad, at least for this test case.
Ian, can you send the patch to google-breakpad? The plan is to move away from stab symbols for google-breakpad, but it's not there yet.
I attached the patch to this bug. I opened issue 359 for google-breakpad.