public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3
@ 2021-05-06 10:33 rdiezmail-gcc at yahoo dot de
2021-05-06 11:14 ` [Bug debug/100446] " rguenth at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: rdiezmail-gcc at yahoo dot de @ 2021-05-06 10:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
@ 2021-05-06 11:14 ` rguenth at gcc dot gnu.org
2021-05-06 11:33 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-06 11:14 UTC (permalink / raw)
To: gcc-bugs
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 ;)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
2021-05-06 11:14 ` [Bug debug/100446] " rguenth at gcc dot gnu.org
@ 2021-05-06 11:33 ` rguenth at gcc dot gnu.org
2021-05-06 11:43 ` rdiezmail-gcc at yahoo dot de
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-06 11:33 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
2021-05-06 11:14 ` [Bug debug/100446] " rguenth at gcc dot gnu.org
2021-05-06 11:33 ` rguenth at gcc dot gnu.org
@ 2021-05-06 11:43 ` rdiezmail-gcc at yahoo dot de
2021-05-06 11:51 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rdiezmail-gcc at yahoo dot de @ 2021-05-06 11:43 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
` (2 preceding siblings ...)
2021-05-06 11:43 ` rdiezmail-gcc at yahoo dot de
@ 2021-05-06 11:51 ` rguenth at gcc dot gnu.org
2021-05-06 12:31 ` rdiezmail-gcc at yahoo dot de
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-05-06 11:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
` (3 preceding siblings ...)
2021-05-06 11:51 ` rguenth at gcc dot gnu.org
@ 2021-05-06 12:31 ` rdiezmail-gcc at yahoo dot de
2021-05-10 20:33 ` tromey at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rdiezmail-gcc at yahoo dot de @ 2021-05-06 12:31 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
` (4 preceding siblings ...)
2021-05-06 12:31 ` rdiezmail-gcc at yahoo dot de
@ 2021-05-10 20:33 ` tromey at gcc dot gnu.org
2021-05-12 20:49 ` simon.marchi at polymtl dot ca
2022-04-19 20:55 ` tromey at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: tromey at gcc dot gnu.org @ 2021-05-10 20:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
` (5 preceding siblings ...)
2021-05-10 20:33 ` tromey at gcc dot gnu.org
@ 2021-05-12 20:49 ` simon.marchi at polymtl dot ca
2022-04-19 20:55 ` tromey at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: simon.marchi at polymtl dot ca @ 2021-05-12 20:49 UTC (permalink / raw)
To: gcc-bugs
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
...
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
` (6 preceding siblings ...)
2021-05-12 20:49 ` simon.marchi at polymtl dot ca
@ 2022-04-19 20:55 ` tromey at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: tromey at gcc dot gnu.org @ 2022-04-19 20:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-04-19 20:55 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-06 10:33 [Bug other/100446] New: GDB has problems reading GCC's debugging info level -g3 rdiezmail-gcc at yahoo dot de
2021-05-06 11:14 ` [Bug debug/100446] " rguenth at gcc dot gnu.org
2021-05-06 11:33 ` rguenth at gcc dot gnu.org
2021-05-06 11:43 ` rdiezmail-gcc at yahoo dot de
2021-05-06 11:51 ` rguenth at gcc dot gnu.org
2021-05-06 12:31 ` rdiezmail-gcc at yahoo dot de
2021-05-10 20:33 ` tromey at gcc dot gnu.org
2021-05-12 20:49 ` simon.marchi at polymtl dot ca
2022-04-19 20:55 ` tromey at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).