Problems reading debug symbols from debug build
640 views
Skip to first unread message
Dominic Hamon
Jan 20, 2012, 2:50:04 PM1/20/12
to chromium-dev
I've successfully built and debug Chrome for months but as of today I am unable to set breakpoints using symbols in gdb (on Linux). I also noticed that when trying to load symbols from the executable I get the error:
Which seems unlikely given everything has been working fine until now.
Load new symbol table from ".../out/Debug/chrome"? (y or n) y
Reading symbols from .../out/Debug/chrome...DW_FORM_strp pointing outside of .debug_str section [in module .../out/Debug/chrome]
The great and powerful Stack Overflow suggests (http://stackoverflow.com/questions/2765078/c-program-debugging-in-gdb-problem):
"Most likely you've compiled your program with a newer version of GCC, but are debugging it with an old GDB.
Else, you have a buggy GCC version, which puts incorrect debug info into your executable."
Which seems unlikely given everything has been working fine until now.
g++ version: g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3
gdb version: GNU gdb (GDB) 7.3.1-gg3
Just in case, I ran install-build-deps.sh but I still see the same error.
Could this be a side-effect of the chrome debug executable size? Is anyone else seeing this?
Evan Martin
Jan 20, 2012, 2:54:17 PM1/20/12
to domi...@chromium.org, chromium-dev
On Fri, Jan 20, 2012 at 11:50 AM, Dominic Hamon <domi...@chromium.org> wrote:
> I've successfully built and debug Chrome for months but as of today I am
> unable to set breakpoints using symbols in gdb (on Linux). I also noticed
> that when trying to load symbols from the executable I get the error:
>
> Load new symbol table from ".../out/Debug/chrome"? (y or n) y
> Reading symbols from .../out/Debug/chrome...DW_FORM_strp pointing outside of
> .debug_str section [in module .../out/Debug/chrome]
> I've successfully built and debug Chrome for months but as of today I am
> unable to set breakpoints using symbols in gdb (on Linux). I also noticed
> that when trying to load symbols from the executable I get the error:
>
> Load new symbol table from ".../out/Debug/chrome"? (y or n) y
> Reading symbols from .../out/Debug/chrome...DW_FORM_strp pointing outside of
> .debug_str section [in module .../out/Debug/chrome]
Could you paste the output of
readelf -h out/Debug/chrome
objdump -h out/Debug/chrome
?
Dominic Hamon
Jan 20, 2012, 3:21:25 PM1/20/12
to Evan Martin, chromium-dev
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x5d74a0
Start of program headers: 64 (bytes into file)
Start of section headers: 891302848 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 10
Size of section headers: 64 (bytes)
Number of section headers: 48
Section header string table index: 47
objdump -h out/Debug/chrome
out/Debug/chrome: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 0000001c 0000000000000270 0000000000000270 00000270 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 000000000000028c 000000000000028c 0000028c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .note.gnu.build-id 00000024 00000000000002ac 00000000000002ac 000002ac 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 0000ebf8 00000000000002d0 00000000000002d0 000002d0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynstr 0000d716 000000000000eec8 000000000000eec8 0000eec8 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .hash 00004770 000000000001c5e0 000000000001c5e0 0001c5e0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.hash 00000178 0000000000020d50 0000000000020d50 00020d50 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .gnu.version 000013aa 0000000000020ec8 0000000000020ec8 00020ec8 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .gnu.version_r 000003c0 0000000000022274 0000000000022274 00022274 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .rela.dyn 0059d600 0000000000022638 0000000000022638 00022638 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 .rela.plt 0000e1c0 00000000005bfc38 00000000005bfc38 005bfc38 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .init 00000018 00000000005cddf8 00000000005cddf8 005cddf8 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .plt 00009690 00000000005cde10 00000000005cde10 005cde10 2**3
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .text 0477c668 00000000005d74a0 00000000005d74a0 005d74a0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
14 malloc_hook 000005ad 0000000004d53b10 0000000004d53b10 04d53b10 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
15 google_malloc 000005cc 0000000004d540c0 0000000004d540c0 04d540c0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
16 .fini 0000000e 0000000004d5468c 0000000004d5468c 04d5468c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
17 .rodata 01186639 0000000004d546a0 0000000004d546a0 04d546a0 2**4
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .gcc_except_table 00001998 0000000005edacdc 0000000005edacdc 05edacdc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
19 .eh_frame 01081fe4 0000000005edc678 0000000005edc678 05edc678 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
20 .eh_frame_hdr 0045591c 0000000006f5e65c 0000000006f5e65c 06f5e65c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
21 .tbss 00000024 00000000073b5780 00000000073b5780 073b4780 2**3
ALLOC, THREAD_LOCAL
22 .data.rel.ro.local 000f6a50 00000000073b5780 00000000073b5780 073b4780 2**4
CONTENTS, ALLOC, LOAD, DATA
23 .ctors 00000458 00000000074ac1d0 00000000074ac1d0 074ab1d0 2**3
CONTENTS, ALLOC, LOAD, DATA
24 .dtors 00000010 00000000074ac628 00000000074ac628 074ab628 2**3
CONTENTS, ALLOC, LOAD, DATA
25 .jcr 00000008 00000000074ac638 00000000074ac638 074ab638 2**3
CONTENTS, ALLOC, LOAD, DATA
26 .data.rel.ro 0014bd20 00000000074ac640 00000000074ac640 074ab640 2**4
CONTENTS, ALLOC, LOAD, DATA
27 .dynamic 000004d0 00000000075f8360 00000000075f8360 075f7360 2**3
CONTENTS, ALLOC, LOAD, DATA
28 .got 0000f7b8 00000000075f8830 00000000075f8830 075f7830 2**3
CONTENTS, ALLOC, LOAD, DATA
29 .got.plt 00004b58 0000000007607fe8 0000000007607fe8 07606fe8 2**3
CONTENTS, ALLOC, LOAD, DATA
30 .data 00023ac8 000000000760cb40 000000000760cb40 0760bb40 2**4
CONTENTS, ALLOC, LOAD, DATA
31 .bss 000a8916 0000000007630610 0000000007630610 0762f610 2**4
ALLOC
32 .comment 00000024 0000000000000000 0000000000000000 0762f608 2**0
CONTENTS, READONLY
33 .debug_info 20e366d4 0000000000000000 0000000000000000 0762f62c 2**0
CONTENTS, READONLY, DEBUGGING
34 .debug_abbrev 0072557e 0000000000000000 0000000000000000 28465d00 2**0
CONTENTS, READONLY, DEBUGGING
35 .debug_aranges 000000f0 0000000000000000 0000000000000000 28b8b27e 2**0
CONTENTS, READONLY, DEBUGGING
36 .debug_macinfo 00000000 0000000000000000 0000000000000000 28b8b36e 2**0
CONTENTS, READONLY, DEBUGGING
37 .debug_line 01cd8a26 0000000000000000 0000000000000000 28b8b36e 2**0
CONTENTS, READONLY, DEBUGGING
38 .debug_loc 0003c86a 0000000000000000 0000000000000000 2a863d94 2**0
CONTENTS, READONLY, DEBUGGING
39 .debug_pubtypes 02802a74 0000000000000000 0000000000000000 2a8a05fe 2**0
CONTENTS, READONLY, DEBUGGING
40 .debug_str 03c30348 0000000000000000 0000000000000000 2d0a3072 2**0
CONTENTS, READONLY, DEBUGGING
41 .debug_ranges 00001f30 0000000000000000 0000000000000000 30cd33ba 2**0
CONTENTS, READONLY, DEBUGGING
42 .debug_frame 00000058 0000000000000000 0000000000000000 30cd52f0 2**3
CONTENTS, READONLY, DEBUGGING
43 .note.gnu.gold-version 0000001c 0000000000000000 0000000000000000 30cd5348 2**2
CONTENTS, READONLY
Evan Martin
Jan 20, 2012, 3:40:49 PM1/20/12
to Dominic Hamon, chromium-dev
On Fri, Jan 20, 2012 at 12:20 PM, Dominic Hamon <domi...@google.com> wrote:
>> > Reading symbols from .../out/Debug/chrome...DW_FORM_strp pointing
>> > outside of
>> > .debug_str section [in module .../out/Debug/chrome]
>> > Reading symbols from .../out/Debug/chrome...DW_FORM_strp pointing
>> > outside of
>> > .debug_str section [in module .../out/Debug/chrome]
I don't know much more than what Google tells me (though I have been
playing with this stuff lately).
One thread indicated that the problem could be multiple .debug_str
sections (which your below output indicates isn't true). And I had
guessed that maybe you were hitting some size limit, but the file is
64-bit ELF (which means 64-bit offsets) and the various ranges look
well within plausible values (the debug_str section is "only" 750mb
into the file).
I guess to be pragmatic about it, I would guess there's either a bug
in your linker or your gdb.
To examine the first, perhaps try building without gold. If it turns
out to be gold, maybe it's the --threads arguments.
To look into those, rm out/Debug/chrome and rebuild with the full
command line (make V=1 or ninja -v), then edit that manually.
Another approach is to build with components, which is what I think
others who aren't encountering this problem are doing.
Ami Fischman
Jan 31, 2012, 7:38:23 PM1/31/12
to ev...@chromium.org, Dominic Hamon, chromium-dev
On Fri, Jan 20, 2012 at 12:40 PM, Evan Martin <ev...@chromium.org> wrote:
Another approach is to build with components, which is what I think
others who aren't encountering this problem are doing.
FTR, combining clang (which Dominic was using in the OP) and the component=shared_library build (which became possible to do with a clang roll earlier this week) causes the DW_FORM_strp problem to be 100% reproducible.
Clang bug filed at http://llvm.org/PR11898.
I haven't seen the problem with clang & static build (Dominic's originally reported config).
-a
Denis Glotov
Mar 30, 2012, 10:16:10 AM3/30/12
to fisc...@chromium.org, ev...@chromium.org, Dominic Hamon, chromium-dev, Dmitry Polukhin, Nikita Kostylev
Any update in this?
--
Thank you,
Denis
Inability to debug binaries built with Clang is painfull.
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Thank you,
Denis
Ami Fischman
Mar 30, 2012, 1:07:03 PM3/30/12
to glo...@chromium.org, ev...@chromium.org, Dominic Hamon, chromium-dev, Dmitry Polukhin, Nikita Kostylev
There hasn't been any chatter on the clang bug I filed, but the bug seems to have got fixed.
My minified repro no longer shows the incorrect DW_FORM_strp and gdb can debug into libcontent.so just fine.
-a
Denis Glotov
Mar 30, 2012, 1:39:31 PM3/30/12
to Ami Fischman, ev...@chromium.org, Dominic Hamon, chromium-dev, Dmitry Polukhin, Nikita Kostylev
Ami, what revision of Clang do you use?
I use 151385. And build Chrome inside the chroot, not using shared_library.
Still I have
(gdb) symbol-file /build/x86-alex/usr/lib/debug/opt/google/chrome/chrome.debug
Reading symbols from /build/x86-alex/usr/lib/debug/opt/google/chrome/chrome.debug...DW_FORM_strp pointing outside of .debug_str section [in module /build/x86-alex/usr/lib/debug/opt/google/chrome/chrome.debug]
--
Thank you,
Denis
Thank you,
Denis
Ami Fischman
Mar 30, 2012, 1:42:06 PM3/30/12
to glo...@chromium.org, ev...@chromium.org, Dominic Hamon, chromium-dev, Dmitry Polukhin, Nikita Kostylev
clang rolled to r153589 earlier today: http://src.chromium.org/viewvc/chrome/trunk/src/tools/clang/scripts/update.sh?&view=markup
(this is the rev I was re-verifying everything worked with this morning)
-a
Denis Glotov
Mar 30, 2012, 3:54:05 PM3/30/12
to Ami Fischman, ev...@chromium.org, Dominic Hamon, chromium-dev, Dmitry Polukhin, Nikita Kostylev
The problem disappeared after upgrading clang and llvm to r153589, thank you!
--
Thank you,
Denis
Thank you,
Denis
Reply all
Reply to author
Forward
0 new messages