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).