[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 --- Comment #8 from Tom Tromey --- This behavior can also be affected by the choice of linker, see bug #91239.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
Simon Marchi changed:
What|Removed |Added
CC||simon.marchi at polymtl dot ca
--- Comment #7 from Simon Marchi ---
Indeed, as soon as I build something with more than two CUs (no LTO involved),
I get these import 0x0:
$ gcc --version
gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat test.c
#include
void foo();
int main() {
foo();
}
$ cat test2.c
#include
void foo()
{
}
$ gcc test.c test2.c -g3 -O0 -o test
$ readelf --debug-dump=macro test | less
...
Offset: 0x1a81
Version: 4
Offset size: 4
Offset into .debug_line: 0x1c1
DW_MACRO_import - offset : 0x0
DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test2.c
DW_MACRO_start_file - lineno: 31 filenum: 2 filename:
/usr/include/stdc-predef.h
DW_MACRO_import - offset : 0x0
DW_MACRO_end_file
DW_MACRO_start_file - lineno: 1 filenum: 3 filename: /usr/include/unistd.h
DW_MACRO_define_strp - lineno : 23 macro : _UNISTD_H 1
DW_MACRO_start_file - lineno: 25 filenum: 4 filename: /usr/include/features.h
DW_MACRO_import - offset : 0x0
DW_MACRO_start_file - lineno: 473 filenum: 5 filename:
/usr/include/sys/cdefs.h
DW_MACRO_import - offset : 0x0
DW_MACRO_start_file - lineno: 462 filenum: 6 filename:
/usr/include/bits/wordsize.h
DW_MACRO_import - offset : 0x0
DW_MACRO_end_file
DW_MACRO_start_file - lineno: 463 filenum: 7 filename:
/usr/include/bits/long-double.h
DW_MACRO_define_strp - lineno : 21 macro : __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI
0
DW_MACRO_end_file
DW_MACRO_import - offset : 0x0
DW_MACRO_end_file
DW_MACRO_start_file - lineno: 497 filenum: 8 filename:
/usr/include/gnu/stubs.h
...
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #6 from Tom Tromey --- (In reply to Richard Biener from comment #1) > I commented on the gdb issue, since -flto/-fno-lto have comparable > .debug_macro the issue must lie with gdb. Sorry for just shifting the blame > ;) If you look at "readelf --debug-dump=macro" on that file, the results are very strange. For example, one of the CUs in the macro section does this: DW_MACRO_import - offset : 0x0 DW_MACRO_end_file ... a total of 108 times. In one spot it does this 3 times in a sequence. That doesn't seem right, or even useful, to me.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 --- Comment #5 from R. Diez --- In a nutshell: "objdump --syms" does not show that symbol, probably because the routine was inlined, but "readelf --debug-dump" does show it. Thanks for your help.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 --- Comment #4 from Richard Biener --- (In reply to R. Diez from comment #3) > Regarding "shifting the blame", no worries, I am grateful for any help. > > I suspect that there is more than 1 issue here. Could you take a look at the > following aspect mentioned in the GDB bug? > > 8<8< > > In fact, I do not understand why StartOfUserCode is not defined in the > release build, because it is the same source code after all. The same > routine is used in the same way. >From just looking at the debug info I see it is inlined into RunUserCode and the offline copy is elided (it's not used from elsewhere). Hint: readelf -w dumps the debug info, you see <1><203aa>: Abbrev Number: 91 (DW_TAG_subprogram) <203ab> DW_AT_external: 1 <203ab> DW_AT_name: (indirect string, offset: 0x7d561): StartOfUserCode ... this is the abstract DIE so look for '203aa' and find <1>: Abbrev Number: 37 (DW_TAG_subprogram) DW_AT_abstract_origin: <0x15d6a> DW_AT_low_pc : 0x860c8 DW_AT_high_pc : 0x9d0 DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) DW_AT_GNU_all_tail_call_sites: 1 DW_AT_sibling : <0xfeeb> <2>: Abbrev Number: 8 (DW_TAG_inlined_subroutine) DW_AT_abstract_origin: <0x203aa> DW_AT_entry_pc: 0x860c8 aha, so inlined into e157 - that's a concrete DIE so look for it's abstract origin 15d6a and find: <1><15d6a>: Abbrev Number: 13 (DW_TAG_subprogram) <15d6b> DW_AT_external: 1 <15d6b> DW_AT_name: (indirect string, offset: 0x69052): RunUserCode ... > I dumped all symbols like this and I compared them: > > arm-none-eabi-objdump --syms firmware-debug-non-lto.elf > arm-none-eabi-objdump --syms firmware-release-lto.elf > > 8<8< > > That particular symbol, StartOfUserCode, among many others, should be in the > release build too. And there is no GDB involved there at all. > > I have not got experience with clang or lldb at all, and I have read that > lldb is not ready yet for debugging bare metal firmware (at least off the > shelf). Might be - I've not used lldb myself either.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 --- Comment #3 from R. Diez --- Regarding "shifting the blame", no worries, I am grateful for any help. I suspect that there is more than 1 issue here. Could you take a look at the following aspect mentioned in the GDB bug? 8<8< In fact, I do not understand why StartOfUserCode is not defined in the release build, because it is the same source code after all. The same routine is used in the same way. I dumped all symbols like this and I compared them: arm-none-eabi-objdump --syms firmware-debug-non-lto.elf arm-none-eabi-objdump --syms firmware-release-lto.elf 8<8< That particular symbol, StartOfUserCode, among many others, should be in the release build too. And there is no GDB involved there at all. I have not got experience with clang or lldb at all, and I have read that lldb is not ready yet for debugging bare metal firmware (at least off the shelf).
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 --- Comment #2 from Richard Biener --- Oh, and just to ask - did you try if lldb behaves "well" here?
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 Richard Biener changed: What|Removed |Added Component|other |debug Keywords||lto CC||rguenth at gcc dot gnu.org See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=27754 --- Comment #1 from Richard Biener --- I commented on the gdb issue, since -flto/-fno-lto have comparable .debug_macro the issue must lie with gdb. Sorry for just shifting the blame ;)
