[Bug gdb/23710] New: gdb is slow and memory hungry consuming debug generated with LTO by GCC

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] New: gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

            Bug ID: 23710
           Summary: gdb is slow and memory hungry consuming debug
                    generated with LTO by GCC
           Product: gdb
           Version: 8.2.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

"Mirror" of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432 where we try to
improve the GCC side.  Input from gdb folks is needed here.

gdb takes ~10s to process a LTO bootstrapped cc1 binary and another two seconds
when setting the first breakpoint.  It also has allocated 1.6GB memory at
that point (compared to ~200MB for a non-LTO binary).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=87432

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
There's http://www.suse.de/~rguenther/cc1.xz you can look at.  It will
eventually run into PR23712 if you poke enough but it survives plain gdb
startup and 'start' for me.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I can re-confirm this with current trunk of gdb and current trunk of gcc.
Things got even slower between gcc 8 and gcc 9. I have uploaded fresh cc1plus
binary to http://www.ucw.cz/~hubicka/cc1plus.gz

It takes a while to load binary and then it takes a while each time function
names are output - i.e. when adding breakpoint, looking on backtraces etc.

Things are a lot worse on Firefox libxul that I can upload too (or it
reproduces with RedHat Fedora package that is now LTO built)

LLDB seems to have no problems. It would be great to have this fixed since it
is quite a problem for adoption of lto.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

Jakub Jelinek <jakub at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com,
                   |                            |jan.kratochvil at redhat dot com,
                   |                            |palves at redhat dot com

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I have spent some time looking into this.  Note that it also affect gdb index
generation that can take well over 10 minutes on bigger binaries built with
LTO, 3 minutes and 1.4GB on cc1plus.

If I comment out code in load_partial_dies that construct partial_die_info
data-structure the startup gets under control.  It seems that this is
processing every DW_TAG_imported_unit and for each of it it allocates the info
data-structure that by itself is 104 bytes.

There are 21830 DW_TAG_imported_unit in cc1plus binary built with LTO. We
default to 128 partitions, so it is 170 per partition.

For some reason 48623044 partial die infos are constructed during gdb index, so
it seems it is tripping same partial dies over and over again?

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #4 from rguenther at suse dot de ---
On Wed, 23 Jan 2019, hubicka at gcc dot gnu.org wrote:

> https://sourceware.org/bugzilla/show_bug.cgi?id=23710
>
> --- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> I have spent some time looking into this.  Note that it also affect gdb index
> generation that can take well over 10 minutes on bigger binaries built with
> LTO, 3 minutes and 1.4GB on cc1plus.
>
> If I comment out code in load_partial_dies that construct partial_die_info
> data-structure the startup gets under control.  It seems that this is
> processing every DW_TAG_imported_unit and for each of it it allocates the info
> data-structure that by itself is 104 bytes.
>
> There are 21830 DW_TAG_imported_unit in cc1plus binary built with LTO. We
> default to 128 partitions, so it is 170 per partition.
>
> For some reason 48623044 partial die infos are constructed during gdb index, so
> it seems it is tripping same partial dies over and over again?

That sounds like a possible explanation.

Still it would be interesting to see why so many (well, 170 per partition
isn't _so_ many) TRANSLATION_UNIT_DECLs end up in the individual
LTRANS units (they'll be the ultimate origin of some decl).

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

Tom de Vries <vries at gcc dot gnu.org> changed:

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

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #5 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #0)
> gdb takes ~10s to process a LTO bootstrapped cc1 binary and another two
> seconds
> when setting the first breakpoint.  It also has allocated 1.6GB memory at
> that point (compared to ~200MB for a non-LTO binary).

There's a setting "maint set/show dwarf max-cache-age" which defaults to 5.

Using a higher setting, I get the following reduction in real execution time:
- 10    :  1.5%
- 100   : 12.5%
- 316   : 16.5%
- 1000  : 16.5%
- 10000 : 16.5%
- 100000: 15.5%

Note: adding the setting to the gdb command line using -iex to make sure it
gets set _before_ loading the exec):
...
$ gdb -q -nw -nx -batch -iex "maint set dwarf max-cache-age $n" -ex "b
do_rpo_vn" cc1
...

Conversely, disabling the cache by setting the value to 0 causes a real
execution time increase of 46%.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #6 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #0)
> "Mirror" of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432 where we try
> to improve the GCC side.  Input from gdb folks is needed here.
>
> gdb takes ~10s to process a LTO bootstrapped cc1 binary and another two
> seconds
> when setting the first breakpoint.  It also has allocated 1.6GB memory at
> that point (compared to ~200MB for a non-LTO binary).

The proposed patch at
https://sourceware.org/ml/gdb-patches/2020-02/msg00974.html allows a speedup
when manually specifying the source language before loading, which takes 17%
off the execution time of loading and setting the first breakpoint.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #7 from Tom de Vries <vries at gcc dot gnu.org> ---
Measuring the two speed workarounds mentioned in comment 5 and 6, it seems
they're complementary:

With loading main full symtab and default max-cache-age:
...
$ ../measure/time.sh ../gdb.sh cc1 -batch -ex "b do_rpo_vn" -iex "maint set
dwarf max-cache-age 5"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1463412
real: 8.92
user: 8.52
system: 0.46
...

With skipping main full symtab and increased max-cache-age:
...
$ ../measure/time.sh ../gdb.sh -iex "set language c++" cc1 -batch -ex "b
do_rpo_vn" -iex "maint set dwarf max-cache-age 316"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 1066220
real: 6.34
user: 6.09
system: 0.31
...

That is: reduction of user execution time by 28,5%.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #8 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #6)

> (In reply to Richard Biener from comment #0)
> > "Mirror" of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432 where we try
> > to improve the GCC side.  Input from gdb folks is needed here.
> >
> > gdb takes ~10s to process a LTO bootstrapped cc1 binary and another two
> > seconds
> > when setting the first breakpoint.  It also has allocated 1.6GB memory at
> > that point (compared to ~200MB for a non-LTO binary).
>
> The proposed patch at
> https://sourceware.org/ml/gdb-patches/2020-02/msg00974.html allows a speedup
> when manually specifying the source language before loading, which takes 17%
> off the execution time of loading and setting the first breakpoint.

That patch has been accepted.

I've submitted a RFC patch that automates this workaround:
https://sourceware.org/ml/gdb-patches/2020-03/msg00009.html .

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #9 from Tom de Vries <vries at gcc dot gnu.org> ---
The cc1 executable contains CUs importing other CUs (as opposed to PUs). By
treating these imports as hints and ignoring them during during symtab
expansion, we can shave off another 8.3%.

Cumulatively, that gets us to user time reduction of 33.5%.

Tentative patch:
...
diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 07cee58c1f..a2a6889f73 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -7425,6 +7425,18 @@ process_psymtab_comp_unit (struct dwarf2_per_cu_data
*this_cu,

   cutu_reader reader (this_cu, NULL, 0, false);

+  switch (reader.comp_unit_die->tag)
+    {
+    case DW_TAG_compile_unit:
+      this_cu->unit_type = DW_UT_compile;
+      break;
+    case DW_TAG_partial_unit:
+      this_cu->unit_type = DW_UT_partial;
+      break;
+    default:
+      abort ();
+    }
+
   if (reader.dummy_p)
     {
       /* Nothing.  */
@@ -9760,6 +9772,9 @@ process_imported_unit_die (struct die_info *die, struct
dwarf2_cu *cu)
        = dwarf2_find_containing_comp_unit (sect_off, is_dwz,
                                            cu->per_cu->dwarf2_per_objfile);

+      if (per_cu->unit_type == DW_UT_compile)
+       return;
+
       /* If necessary, add it to the queue and load its DIEs.  */
       if (maybe_queue_comp_unit (cu, per_cu, cu->language))
        load_full_comp_unit (per_cu, false, cu->language);
diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h
index 00652c2b45..58b80d4821 100644
--- a/gdb/dwarf2/read.h
+++ b/gdb/dwarf2/read.h
@@ -323,6 +323,8 @@ struct dwarf2_per_cu_data
      dummy CUs (a CU header, but nothing else).  */
   struct dwarf2_cu *cu;

+  enum dwarf_unit_type unit_type;
+
   /* The corresponding dwarf2_per_objfile.  */
   struct dwarf2_per_objfile *dwarf2_per_objfile;

...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #10 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #9)
> The cc1 executable contains CUs importing other CUs (as opposed to PUs). By
> treating these imports as hints and ignoring them during during symtab
> expansion, we can shave off another 8.3%.
>
> Cumulatively, that gets us to user time reduction of 33.5%.
>
> Tentative patch:

Submitted: https://sourceware.org/ml/gdb-patches/2020-03/msg00026.html .

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Comparison, cc1 vs cc1.dwz (produced using dwz build from current master
branch):
...
$ diff.sh cc1 cc1.dwz
.debug_info      red: 49.30%    97418416  49399513
.debug_abbrev    red: 42.04%     1699940    985372
.debug_str       red: 0%         6344030   6344030
total            red: 46.21%   105462386  56728915
...

lldb roughly uses same amount of memory, that is: cc1.dwz uses 5.7% less:
...
$ time.sh lldb -batch cc1 -o "b do_rpo_vn"
(lldb) target create "cc1"
Current executable set to 'cc1' (x86_64).
(lldb) b do_rpo_vn
Breakpoint 1: 3 locations.
maxmem: 519116
real: 2.63
user: 4.21
system: 0.14
$ time.sh lldb -batch cc1.dwz -o "b do_rpo_vn"
(lldb) target create "cc1.dwz"
Current executable set to 'cc1.dwz' (x86_64).
(lldb) b do_rpo_vn
Breakpoint 1: 3 locations.
maxmem: 489596
real: 2.78
user: 4.01
system: 0.10
...

With gdb, the difference is a reduction of 51.9%:
...
$ time.sh gdb cc1 -batch -iex "set language c++" -iex "maint set dwarf
max-cache-age 316" -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 999404
real: 7.03
user: 6.81
system: 0.25
$ time.sh gdb cc1.dwz -batch -iex "set language c++" -iex "maint set dwarf
max-cache-age 316" -ex "b do_rpo_vn"
Breakpoint 1 at 0xd40e30: do_rpo_vn. (2 locations)
maxmem: 481152
real: 6.15
user: 6.09
system: 0.12
...

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

glaubitz at physik dot fu-berlin.de
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #12 from Jan Kratochvil <jan.kratochvil at redhat dot com> ---
(In reply to Tom de Vries from comment #11)
> $ time.sh lldb -batch cc1.dwz -o "b do_rpo_vn"

FYI upstream LLDB does not yet support DWZ to make such measurement valid.
There is an off-trunk patchset for it:
  git clone -b dwz git://git.jankratochvil.net/lldb
It works but it is still being refactored to get it accepted upstream.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #13 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <[hidden email]>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=589902954da0d1dd140b33e578954746c9bfc374

commit 589902954da0d1dd140b33e578954746c9bfc374
Author: Tom de Vries <[hidden email]>
Date:   Tue Mar 17 08:56:36 2020 +0100

    [gdb] Skip imports of c++ CUs

    The DWARF standard appendix E.1 describes techniques that can be used for
    compression and deduplication: DIEs can be factored out into a new
compilation
    unit, and referenced using DW_FORM_ref_addr.

    Such a new compilation unit can either use a DW_TAG_compile_unit or
    DW_TAG_partial_unit.  If a DW_TAG_compile_unit is used, its contents is
    evaluated by consumers as though it were an ordinary compilation unit.  If
a
    DW_TAG_partial_unit is used, it's only considered by consumers in the
context
    of a DW_TAG_imported_unit.

    An example of when DW_TAG_partial_unit is required is when the factored out
    DIEs are not top-level, f.i. because they were children of a namespace.  In
    such a case the corresponding DW_TAG_imported_unit will occur as child of
the
    namespace.

    In the case of factoring out DIEs from c++ compilation units, we can factor
    out into a new DW_TAG_compile_unit, and no DW_TAG_imported_unit is
required.

    This begs the question how to interpret a top-level DW_TAG_imported_unit of
a
    c++ DW_TAG_compile_unit compilation unit.  The semantics of
    DW_TAG_imported_unit describe that the imported unit logically appears at
the
    point of the DW_TAG_imported_unit entry.  But it's not clear what the
effect
    should be in this case, since all the imported DIEs are already globally
    visible anyway, due to the use of DW_TAG_compile_unit.

    So, skip top-level imports of c++ DW_TAG_compile_unit compilation units in
    process_imported_unit_die.

    Using the cc1 binary from PR23710 comment 1 and setting a breakpoint on
do_rpo_vn:
    ...
    $ gdb \
        -batch \
        -iex "maint set dwarf max-cache-age 316" \
        -iex "set language c++" \
        -ex "b do_rpo_vn" \
        cc1
    ...
    we get a 8.1% reduction in execution time, due to reducing the number of
    partial symtabs expanded into full symtabs from 212 to 175.

    Build and reg-tested on x86_64-linux.

    gdb/ChangeLog:

    2020-03-17  Tom de Vries  <[hidden email]>

            PR gdb/23710
            * dwarf2/read.h (struct dwarf2_per_cu_data): Add unit_type and lang
            fields.
            * dwarf2/read.c (process_psymtab_comp_unit): Initialize unit_type
and lang
            fields.
            (process_imported_unit_die): Skip import of c++ CUs.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #14 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #5)

> (In reply to Richard Biener from comment #0)
> > gdb takes ~10s to process a LTO bootstrapped cc1 binary and another two
> > seconds
> > when setting the first breakpoint.  It also has allocated 1.6GB memory at
> > that point (compared to ~200MB for a non-LTO binary).
>
> There's a setting "maint set/show dwarf max-cache-age" which defaults to 5.
>
> Using a higher setting, I get the following reduction in real execution time:
> - 10    :  1.5%
> - 100   : 12.5%
> - 316   : 16.5%
> - 1000  : 16.5%
> - 10000 : 16.5%
> - 100000: 15.5%
>
> Note: adding the setting to the gdb command line using -iex to make sure it
> gets set _before_ loading the exec):
> ...
> $ gdb -q -nw -nx -batch -iex "maint set dwarf max-cache-age $n" -ex "b
> do_rpo_vn" cc1
> ...
>
> Conversely, disabling the cache by setting the value to 0 causes a real
> execution time increase of 46%.

Filed PR25703 - "set dwarf max-cache-age default of 5 is slow for
inter-CU-reference binaries".

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

--- Comment #15 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #8)

> (In reply to Tom de Vries from comment #6)
> > (In reply to Richard Biener from comment #0)
> > > "Mirror" of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432 where we try
> > > to improve the GCC side.  Input from gdb folks is needed here.
> > >
> > > gdb takes ~10s to process a LTO bootstrapped cc1 binary and another two
> > > seconds
> > > when setting the first breakpoint.  It also has allocated 1.6GB memory at
> > > that point (compared to ~200MB for a non-LTO binary).
> >
> > The proposed patch at
> > https://sourceware.org/ml/gdb-patches/2020-02/msg00974.html allows a speedup
> > when manually specifying the source language before loading, which takes 17%
> > off the execution time of loading and setting the first breakpoint.
>
> That patch has been accepted.
>
> I've submitted a RFC patch that automates this workaround:
> https://sourceware.org/ml/gdb-patches/2020-03/msg00009.html .

Committed:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d3214198119c1a2f9a6a2b8fcc56d8c324e1a245

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

Sourceware - gdb-prs mailing list
In reply to this post by glaubitz at physik dot fu-berlin.de
https://sourceware.org/bugzilla/show_bug.cgi?id=23710

rdiezmail-binutils at yahoo dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rdiezmail-binutils at yahoo dot de

--
You are receiving this mail because:
You are on the CC list for the bug.
12