public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/97718] New: [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"
@ 2020-11-04 18:51 tschwinge at gcc dot gnu.org
2020-11-05 7:39 ` [Bug debug/97718] " rguenth at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: tschwinge at gcc dot gnu.org @ 2020-11-04 18:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
Bug ID: 97718
Summary: [11 regression] Excessive GDB memory usage after GCC
"Save some memory at debug stream-in time"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tschwinge at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
As of commit r11-4664-g104ca9cfa60aa1d5dd6666d3574bed012d394e8c "Save some
memory at debug stream-in time", I notice excessive GDB memory usage for
certain testcases, for example:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26165 tschwing 20 0 6514108 6.087g 5752 R 99.1 39.0 1:07.45 gdb -nx
-nw -quiet -batch -x pr54519-4.gdb ./pr54519-4.exe
(Growing much bigger, rendering the GCC testsuite unusable due to thrashing,
timeouts.)
This is on an up-to-date Ubuntu 14.04 x86_64 GNU/Linux system using:
- GNU assembler (GNU Binutils for Ubuntu) 2.24
- GNU ld (GNU Binutils for Ubuntu) 2.24
- GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.3) 7.7.1
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"
2020-11-04 18:51 [Bug debug/97718] New: [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time" tschwinge at gcc dot gnu.org
@ 2020-11-05 7:39 ` rguenth at gcc dot gnu.org
2020-11-05 8:26 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-05 7:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |11.0
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed| |2020-11-05
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I will investigate another report of a FAILing guality test today and
eventually revert.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"
2020-11-04 18:51 [Bug debug/97718] New: [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time" tschwinge at gcc dot gnu.org
2020-11-05 7:39 ` [Bug debug/97718] " rguenth at gcc dot gnu.org
@ 2020-11-05 8:26 ` rguenth at gcc dot gnu.org
2020-11-05 9:20 ` cvs-commit at gcc dot gnu.org
2020-11-05 9:21 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-05 8:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Using gdb 8.3.1 on openSUSE Leap 15.2 doesn't show the excessive memory use.
The only difference in readelf -w of the binary before/after the patch is
--- /tmp/a 2020-11-05 08:58:26.636803199 +0100
+++ /tmp/b 2020-11-05 08:58:29.912837061 +0100
@@ -280,7 +280,7 @@
<142> DW_AT_abstract_origin: <0x2f9>
<146> DW_AT_location : 1 byte block: 54 (DW_OP_reg4 (rsi))
<2><148>: Abbrev Number: 5 (DW_TAG_inlined_subroutine)
- <149> DW_AT_abstract_origin: <0x2df>
+ <149> DW_AT_abstract_origin: <0x119>
<14d> DW_AT_entry_pc : 0x4004e0
<155> DW_AT_GNU_entry_view: 0
<156> DW_AT_low_pc : 0x4004e0
@@ -756,7 +756,7 @@
DW_AT_location DW_FORM_exprloc
DW_AT value: 0 DW_FORM value: 0
5 DW_TAG_inlined_subroutine [has children]
- DW_AT_abstract_origin DW_FORM_ref_addr
+ DW_AT_abstract_origin DW_FORM_ref4
DW_AT_entry_pc DW_FORM_addr
DW_AT_GNU_entry_view DW_FORM_data1
DW_AT_low_pc DW_FORM_addr
unpatched the abstract origin directly refered to the abstract origin of the
now refered DIE:
<1><119>: Abbrev Number: 2 (DW_TAG_subprogram)
<11a> DW_AT_abstract_origin: <0x2df>
<11e> DW_AT_low_pc : 0x4004d0
<126> DW_AT_high_pc : 0x40
<12e> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<130> DW_AT_GNU_all_call_sites: 1
<130> DW_AT_sibling : <0x1ff>
...
<1><2df>: Abbrev Number: 9 (DW_TAG_subprogram)
<2e0> DW_AT_name : fn2
<2e4> DW_AT_decl_file : 1
<2e5> DW_AT_decl_line : 12
<2e6> DW_AT_decl_column : 1
<2e7> DW_AT_prototyped : 1
<2e7> DW_AT_type : <0x2ad>
<2eb> DW_AT_sibling : <0x304>
I guess we're splitting / re-inlining fn2 here. The way the patch has
an effect is via
static inline void
add_abstract_origin_attribute (dw_die_ref die, tree origin)
{
dw_die_ref origin_die = NULL;
/* For late LTO debug output we want to refer directly to the abstract
DIE in the early debug rather to the possibly existing concrete
instance and avoid creating that just for this purpose. */
sym_off_pair *desc;
if (in_lto_p
&& external_die_map
&& (desc = external_die_map->get (origin)))
{
add_AT_external_die_ref (die, DW_AT_abstract_origin,
desc->sym, desc->off);
return;
}
which previously made the direct reference to the early debug origin
even when a local DIE for it was already created.
We can fix this by unwrapping one level.
Now the interesting thing is that before the change we had
FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none -DPREVENT_OPTIMIZATION line 17 y == 25
FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 17 y == 25
while after it
FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none -DPREVENT_OPTIMIZATION line 22 y == 68
FAIL: gcc.dg/guality/pr54519-4.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 22 y == 68
clearly the old DWARF was better so I'm going to restore it but sth in the
location list processing seems off ...
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"
2020-11-04 18:51 [Bug debug/97718] New: [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time" tschwinge at gcc dot gnu.org
2020-11-05 7:39 ` [Bug debug/97718] " rguenth at gcc dot gnu.org
2020-11-05 8:26 ` rguenth at gcc dot gnu.org
@ 2020-11-05 9:20 ` cvs-commit at gcc dot gnu.org
2020-11-05 9:21 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-05 9:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:
https://gcc.gnu.org/g:1436ef2a57e79b6b8ce5b03e32a38dd64f46c97c
commit r11-4733-g1436ef2a57e79b6b8ce5b03e32a38dd64f46c97c
Author: Richard Biener <rguenther@suse.de>
Date: Thu Nov 5 09:27:28 2020 +0100
debug/97718 - fix abstract origin references after last change
The change to clear the external_die_map slot after creating
the concrete instance DIE broke abstract origin processing which
tried to make sure to have those point to the early abstract instance
and not the concrete instance. The following restores this by
eventually following the abstract origin link in the concrete instance.
2020-11-05 Richard Biener <rguenther@suse.de>
PR debug/97718
* dwarf2out.c (add_abstract_origin_attribute): Make sure to
point to the abstract instance.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug debug/97718] [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time"
2020-11-04 18:51 [Bug debug/97718] New: [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time" tschwinge at gcc dot gnu.org
` (2 preceding siblings ...)
2020-11-05 9:20 ` cvs-commit at gcc dot gnu.org
@ 2020-11-05 9:21 ` rguenth at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-05 9:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97718
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed now.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-11-05 9:21 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-04 18:51 [Bug debug/97718] New: [11 regression] Excessive GDB memory usage after GCC "Save some memory at debug stream-in time" tschwinge at gcc dot gnu.org
2020-11-05 7:39 ` [Bug debug/97718] " rguenth at gcc dot gnu.org
2020-11-05 8:26 ` rguenth at gcc dot gnu.org
2020-11-05 9:20 ` cvs-commit at gcc dot gnu.org
2020-11-05 9:21 ` rguenth 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).