[Bug debug/87432] LTO produced debug info makes gdb slow

[tromey at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #2 from Tom Tromey  ---
(In reply to Richard Biener from comment #0)
> For example starting gdb on LTO bootstrapped cc1 takes s and ~1.8GB memory
> for me.  Setting a breakpoint on do_rpo_vn takes another 3s.  That feels a
> lot slower than doing this on a non-LTO bootstrapped cc1.
> 
> This bug is to track what _GCC_ can do better here.

Note that in gdb, those are two different code paths.

We recently rewrote the initial scan to be much faster (10x improvement
isn't uncommon).  This affects the startup time.

However, setting a breakpoint currently requires a full CU expansion.
That's still probably slow.  For gdb performance the best thing for
this case is if each CU is reasonably small.

[Bug debug/87432] LTO produced debug info makes gdb slow

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-25
 CC||vries at gcc dot gnu.org
Version|8.2.1   |9.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87362#c6 for some profiling of
gdb - the time is spent building its symbol table and the memory is likely used
because it pulls in all (too many) DIEs.