Bug ID: 24624
Summary: Using -ggdb3 and linking with ld.lld leads to
cpu/memory hog in gdb
Assignee: unassigned at sourceware dot org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
I am reporting here an issue that is initially a ld.lld bug (that I reported
here https://bugs.llvm.org/show_bug.cgi?id=42030 if you want to see the
details), which in the end triggers a cpu/memory hog + huge slowness in
displaying backtraces in gdb.
As you can see in the lld bug, the problem is lld doesn't update the offset of
DW_MACRO_import at link time, so it remains at value 0x0 for ever. When you
have a big number of entries in .debug_macros, then gdb is very slow (up to 30
minutes to display a stack trace in our real world case). You had a somewhat
similar issue in http://sourceware.org/bugzilla/show_bug.cgi?id=13568 with
Do you see any possible workaround in gdb to cope with these buggy
compiler/linker ? For now I have patched gdb in this way:
(Basically the "idea" is quite stupid but at least "works" in my case: consider
that for DW_MACRO_import the value "0" is most likely invalid, so just ignore
such cases: "if (macinfo_type == DW_MACRO_import_sup || offset != 0)"
Do you think such a workaround makes sense and is it really true that offset
shall never be 0 ? Or do you see any other way to workaround this (if it is
worth working around a lld bug) ?
You are receiving this mail because:
You are on the CC list for the bug.