* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
@ 2022-05-26 18:06 ` simark at simark dot ca
2022-05-26 18:24 ` rajpal.gusain at gmail dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: simark at simark dot ca @ 2022-05-26 18:06 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
Simon Marchi <simark at simark dot ca> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |simark at simark dot ca
--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
By the looks of you backtraces (GDB stuck in processing macro information), I
am guessing that it's the same as:
https://sourceware.org/bugzilla/show_bug.cgi?id=27754
If you run "readelf --debug-dump=macro" on your binary, do you get a ton of
DW_MACRO_import - offset : 0x0
? If so it's a problem in the compiler or linker. It has apparently been
fixed (you can follow the paper trail on that bug), but I don't really
understand the details on that side.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
2022-05-26 18:06 ` [Bug gdb/29188] " simark at simark dot ca
@ 2022-05-26 18:24 ` rajpal.gusain at gmail dot com
2022-05-26 18:41 ` simark at simark dot ca
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rajpal.gusain at gmail dot com @ 2022-05-26 18:24 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #2 from gusain <rajpal.gusain at gmail dot com> ---
Thanks for your suggestion but no there isn't even a single occurrence of it.
% readelf --debug-dump=macro <mybinary>
%
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
2022-05-26 18:06 ` [Bug gdb/29188] " simark at simark dot ca
2022-05-26 18:24 ` rajpal.gusain at gmail dot com
@ 2022-05-26 18:41 ` simark at simark dot ca
2022-05-27 10:52 ` rajpal.gusain at gmail dot com
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: simark at simark dot ca @ 2022-05-26 18:41 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
(In reply to gusain from comment #2)
> Thanks for your suggestion but no there isn't even a single occurrence of it.
>
> % readelf --debug-dump=macro <mybinary>
> %
This is surprising given that you said you compiled with -g3. And your
backtraces show GDB reading some macro information. It could also be in a
shared library, though.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (2 preceding siblings ...)
2022-05-26 18:41 ` simark at simark dot ca
@ 2022-05-27 10:52 ` rajpal.gusain at gmail dot com
2022-05-27 12:50 ` simark at simark dot ca
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rajpal.gusain at gmail dot com @ 2022-05-27 10:52 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #4 from gusain <rajpal.gusain at gmail dot com> ---
I did check shared libraries and I couldn't find it there either. Is there any
other way to confirm it's the same issue?
If there is more information needed to narrow it further, can you let me know ?
Also, I checked other ticket and I have two comments
1. LTO is not in picture here
2. I have tried lld and gold as well but none seems to fix the issue.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (3 preceding siblings ...)
2022-05-27 10:52 ` rajpal.gusain at gmail dot com
@ 2022-05-27 12:50 ` simark at simark dot ca
2022-05-27 12:57 ` tromey at sourceware dot org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: simark at simark dot ca @ 2022-05-27 12:50 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #5 from Simon Marchi <simark at simark dot ca> ---
Well, your backtraces do show GDB reading macro information, so there's gotta
be some somewhere.
Actually, you can turn on:
(gdb) set debug dwarf-read 1
prior to running your experiment. You should get some messages like this, that
will help you know which CU in which file GDB is slow at reading:
[dwarf-read] process_queue: Expanding one or more symtabs of objfile
/home/simark/build/binutils-gdb-one-target/gdb/gdb ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x1054
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (4 preceding siblings ...)
2022-05-27 12:50 ` simark at simark dot ca
@ 2022-05-27 12:57 ` tromey at sourceware dot org
2022-05-27 13:43 ` simark at simark dot ca
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: tromey at sourceware dot org @ 2022-05-27 12:57 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org
--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
I tend to think this is a dup as well.
The way gcc emits the macro info also triggered a problem with mold.
Maybe gdb should just ignore imports of 0x0 as a workaround.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (5 preceding siblings ...)
2022-05-27 12:57 ` tromey at sourceware dot org
@ 2022-05-27 13:43 ` simark at simark dot ca
2022-05-27 15:11 ` rajpal.gusain at gmail dot com
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: simark at simark dot ca @ 2022-05-27 13:43 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
(In reply to Tom Tromey from comment #6)
> I tend to think this is a dup as well.
>
> The way gcc emits the macro info also triggered a problem with mold.
> Maybe gdb should just ignore imports of 0x0 as a workaround.
I'm just worried that there could be legitimate cases of "import 0".
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (6 preceding siblings ...)
2022-05-27 13:43 ` simark at simark dot ca
@ 2022-05-27 15:11 ` rajpal.gusain at gmail dot com
2022-06-03 20:31 ` rajpal.gusain at gmail dot com
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rajpal.gusain at gmail dot com @ 2022-05-27 15:11 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #8 from gusain <rajpal.gusain at gmail dot com> ---
(In reply to Simon Marchi from comment #5)
> Well, your backtraces do show GDB reading macro information, so there's
> gotta be some somewhere.
>
> Actually, you can turn on:
>
> (gdb) set debug dwarf-read 1
>
> prior to running your experiment. You should get some messages like this,
> that will help you know which CU in which file GDB is slow at reading:
>
> [dwarf-read] process_queue: Expanding one or more symtabs of objfile
> /home/simark/build/binutils-gdb-one-target/gdb/gdb ...
> [dwarf-read] process_queue: Expanding symtab of CU at offset 0x1054
Thanks, and yes now it prints and appears to be stuck when I try breakpoint
completion by hitting tab after name hint
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x5d2cd20
[dwarf-read] process_queue: Done expanding CU at offset 0x5d2cd20
[dwarf-read] process_queue: Done expanding symtabs of <binary>.
[dwarf-read] process_queue: Expanding one or more symtabs of objfile <binary>
...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x3644296
[dwarf-read] process_queue: Done expanding CU at offset 0x3644296
[dwarf-read] process_queue: Done expanding symtabs of <binary>.
[dwarf-read] process_queue: Expanding one or more symtabs of objfile <binary>
...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x2cc08bb
[dwarf-read] process_queue: Done expanding CU at offset 0x2cc08bb
[dwarf-read] process_queue: Done expanding symtabs of <binary>.
[dwarf-read] process_queue: Expanding one or more symtabs of objfile <binary>
...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x18f13e
[dwarf-read] process_queue: Done expanding CU at offset 0x18f13e
[dwarf-read] process_queue: Done expanding symtabs of <binary>.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (7 preceding siblings ...)
2022-05-27 15:11 ` rajpal.gusain at gmail dot com
@ 2022-06-03 20:31 ` rajpal.gusain at gmail dot com
2022-06-04 16:12 ` tromey at sourceware dot org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rajpal.gusain at gmail dot com @ 2022-06-03 20:31 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #9 from gusain <rajpal.gusain at gmail dot com> ---
(In reply to gusain from comment #8)
> (In reply to Simon Marchi from comment #5)
> > Well, your backtraces do show GDB reading macro information, so there's
> > gotta be some somewhere.
> >
> > Actually, you can turn on:
> >
> > (gdb) set debug dwarf-read 1
> >
> > prior to running your experiment. You should get some messages like this,
> > that will help you know which CU in which file GDB is slow at reading:
> >
> > [dwarf-read] process_queue: Expanding one or more symtabs of objfile
> > /home/simark/build/binutils-gdb-one-target/gdb/gdb ...
> > [dwarf-read] process_queue: Expanding symtab of CU at offset 0x1054
>
>
> Thanks, and yes now it prints and appears to be stuck when I try breakpoint
> completion by hitting tab after name hint
>
> [dwarf-read] process_queue: Expanding symtab of CU at offset 0x5d2cd20
> [dwarf-read] process_queue: Done expanding CU at offset 0x5d2cd20
> [dwarf-read] process_queue: Done expanding symtabs of <binary>.
> [dwarf-read] process_queue: Expanding one or more symtabs of objfile
> <binary> ...
> [dwarf-read] process_queue: Expanding symtab of CU at offset 0x3644296
> [dwarf-read] process_queue: Done expanding CU at offset 0x3644296
> [dwarf-read] process_queue: Done expanding symtabs of <binary>.
> [dwarf-read] process_queue: Expanding one or more symtabs of objfile
> <binary> ...
> [dwarf-read] process_queue: Expanding symtab of CU at offset 0x2cc08bb
> [dwarf-read] process_queue: Done expanding CU at offset 0x2cc08bb
> [dwarf-read] process_queue: Done expanding symtabs of <binary>.
> [dwarf-read] process_queue: Expanding one or more symtabs of objfile
> <binary> ...
> [dwarf-read] process_queue: Expanding symtab of CU at offset 0x18f13e
> [dwarf-read] process_queue: Done expanding CU at offset 0x18f13e
> [dwarf-read] process_queue: Done expanding symtabs of <binary>.
Is there any other information I can get to confirm it's same as other issue
you mentioned ?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (8 preceding siblings ...)
2022-06-03 20:31 ` rajpal.gusain at gmail dot com
@ 2022-06-04 16:12 ` tromey at sourceware dot org
2022-06-04 17:46 ` rajpal.gusain at gmail dot com
2022-10-25 16:16 ` tromey at sourceware dot org
11 siblings, 0 replies; 13+ messages in thread
From: tromey at sourceware dot org @ 2022-06-04 16:12 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #10 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to gusain from comment #9)
> Is there any other information I can get to confirm it's same as other issue
> you mentioned ?
Try something like:
readelf --debug-dump=macro | grep 'import.* 0x0$'
See bug #27754
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (9 preceding siblings ...)
2022-06-04 16:12 ` tromey at sourceware dot org
@ 2022-06-04 17:46 ` rajpal.gusain at gmail dot com
2022-10-25 16:16 ` tromey at sourceware dot org
11 siblings, 0 replies; 13+ messages in thread
From: rajpal.gusain at gmail dot com @ 2022-06-04 17:46 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
--- Comment #11 from gusain <rajpal.gusain at gmail dot com> ---
Thanks for your help. It does seem like it's similar to 27754 but let me share
few observations
% readelf --debug-dump=macro ld-g | grep 'import.*0x0$' | wc -l
277652
% readelf --debug-dump=macro lld-g | grep 'import.*0x0$' | wc -l
277655
% readelf --debug-dump=macro gold-g | grep 'import.*0x0$' | wc -l
0
You had a comment on other ticket that it doesn't seem to affect lld but my
binary linked with ldd doesn't suggest it.
With gold, I have 0 occurrences but binary is no good because when I bring it
up in gdb, source information seems to be incorrect. When I put a breakpoint in
my code, gdb tells me that it's in some libstdc++ file.
Do you still think it's not gdb bug ? If not, whose bug is it ?
Are you aware of any workaround (gold link doesn't work for me and I have other
issues with it as I mentioned before) ?
Do you think it's gold linker bug and I should file a ticket for it ? Is there
information I can get which can shed more light on this gold-linked binary
issue ?
(In reply to Tom Tromey from comment #10)
> (In reply to gusain from comment #9)
>
> > Is there any other information I can get to confirm it's same as other issue
> > you mentioned ?
>
> Try something like:
>
> readelf --debug-dump=macro | grep 'import.* 0x0$'
>
> See bug #27754
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug gdb/29188] gdb too slow and hogs memory for debug binary generated with gcc 11.2
2022-05-26 17:30 [Bug gdb/29188] New: gdb too slow and hogs memory for debug binary generated with gcc 11.2 rajpal.gusain at gmail dot com
` (10 preceding siblings ...)
2022-06-04 17:46 ` rajpal.gusain at gmail dot com
@ 2022-10-25 16:16 ` tromey at sourceware dot org
11 siblings, 0 replies; 13+ messages in thread
From: tromey at sourceware dot org @ 2022-10-25 16:16 UTC (permalink / raw)
To: gdb-prs
https://sourceware.org/bugzilla/show_bug.cgi?id=29188
Tom Tromey <tromey at sourceware dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #12 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to gusain from comment #11)
> With gold, I have 0 occurrences but binary is no good because when I bring
> it up in gdb, source information seems to be incorrect. When I put a
> breakpoint in my code, gdb tells me that it's in some libstdc++ file.
This sounds like a different problem, which we'd have to investigate
separately.
> Do you still think it's not gdb bug ? If not, whose bug is it ?
I think the mold author put in a workaround for this issue.
While pedantically it may be a gcc bug, in practice the fixes are in the
linker.
> Are you aware of any workaround (gold link doesn't work for me and I have
> other issues with it as I mentioned before) ?
GNU ld should work, or an updated mold. I'm unsure about lld.
> Do you think it's gold linker bug and I should file a ticket for it ? Is
> there information I can get which can shed more light on this gold-linked
> binary issue ?
I'm afraid I don't know the answer here.
Since I think this particular bug is another instance of the macro-import
problem, I'm closing it as a dup.
*** This bug has been marked as a duplicate of bug 27754 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 13+ messages in thread