[Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3

[Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3

[rdiezmail-gcc at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

            Bug ID: 100446
           Summary: GDB has problems reading GCC's debugging info level
                    -g3
           Product: gcc
           Version: 10.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rdiezmail-gcc at yahoo dot de
  Target Milestone: ---

GDB has excessive CPU load and memory usage with -g3 debug info. Sometimes it
makes GDB unusable.

There are problems with debug (non LTO) builds, but most issues come with when
building with LTO, like for example missing or weird C++ symbols. The release
ELF seems to have lost most C++ symbols, and there are many entries like this:

00010d6b l       .debug_info    00000000 
00010d6b l       .debug_info    00000000 
00010d6b l       .debug_info    00000000 
00010d6b l       .debug_info    00000000 

More details about this problem are here:

https://sourceware.org/bugzilla/show_bug.cgi?id=27754

It looks like a GCC issue, and not a GDB issue.

I asked in the mailing list but got no answer at all:

https://gcc.gnu.org/pipermail/gcc-help/2021-April/140221.html

[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
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 ;)

[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
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

[rdiezmail-gcc at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

--- Comment #3 from R. Diez <rdiezmail-gcc at yahoo dot de> ---
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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(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><e157>: Abbrev Number: 37 (DW_TAG_subprogram)
    <e158>   DW_AT_abstract_origin: <0x15d6a>
    <e15c>   DW_AT_low_pc      : 0x860c8
    <e160>   DW_AT_high_pc     : 0x9d0
    <e164>   DW_AT_frame_base  : 1 byte block: 9c       (DW_OP_call_frame_cfa)
    <e166>   DW_AT_GNU_all_tail_call_sites: 1
    <e166>   DW_AT_sibling     : <0xfeeb>
 <2><e16a>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
    <e16b>   DW_AT_abstract_origin: <0x203aa>
    <e16f>   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

[rdiezmail-gcc at yahoo dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

--- Comment #5 from R. Diez <rdiezmail-gcc at yahoo dot de> ---
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

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

Tom Tromey <tromey at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu.org

--- Comment #6 from Tom Tromey <tromey at gcc dot gnu.org> ---
(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

[simon.marchi at polymtl dot ca]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #7 from Simon Marchi <simon.marchi at polymtl dot ca> ---
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 <unistd.h>

void foo();

int main() {
    foo();
}
$ cat test2.c
#include <unistd.h>

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

[tromey at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446

--- Comment #8 from Tom Tromey <tromey at gcc dot gnu.org> ---
This behavior can also be affected by the choice of linker,
see bug #91239.