| Summary: | LTO produced debug info makes gdb slow | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Richard Biener <rguenth> |
| Component: | debug | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | dimhen, michael.hliao, sjames, tromey, vries |
| Priority: | P3 | Keywords: | lto |
| Version: | 9.0 | ||
| Target Milestone: | --- | ||
| See Also: | https://sourceware.org/bugzilla/show_bug.cgi?id=23710 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2018-09-25 00:00:00 | |
|
Description
Richard Biener
2018-09-25 12:55:44 UTC
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. (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. |