[Bug backtrace/24624] New: Using -ggdb3 and linking with ld.lld leads to cpu/memory hog in gdb

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[Bug backtrace/24624] New: Using -ggdb3 and linking with ld.lld leads to cpu/memory hog in gdb

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=24624

            Bug ID: 24624
           Summary: Using -ggdb3 and linking with ld.lld leads to
                    cpu/memory hog in gdb
           Product: gdb
           Version: 8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: backtrace
          Assignee: unassigned at sourceware dot org
          Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

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
buggy compiler/linker.

Do you see any possible workaround in gdb to cope with these buggy
compiler/linker ? For now I have patched gdb in this way:

--- gdb/dwarf2read.c
+++ gdb/dwarf2read.c
@@ -24597,27 +24597,30 @@
                is_dwz = 1;
              }

-           new_mac_ptr = include_section->buffer + offset;
-           slot = htab_find_slot (include_hash, new_mac_ptr, INSERT);
+        if (macinfo_type == DW_MACRO_import_sup || offset != 0)
+        {  
+            new_mac_ptr = include_section->buffer + offset;
+            slot = htab_find_slot (include_hash, new_mac_ptr, INSERT);

-           if (*slot != NULL)
-             {
-               /* This has actually happened; see
-                  http://sourceware.org/bugzilla/show_bug.cgi?id=13568.  */
-               complaint (_("recursive DW_MACRO_import in "
-                            ".debug_macro section"));
-             }
-           else
-             {
-               *slot = (void *) new_mac_ptr;
+            if (*slot != NULL)
+              {
+            /* This has actually happened; see  
+               http://sourceware.org/bugzilla/show_bug.cgi?id=13568.  */
+            complaint (_("recursive DW_MACRO_import in "
+                     ".debug_macro section"));  
+              }
+            else
+              {
+            *slot = (void *) new_mac_ptr;

-               dwarf_decode_macro_bytes (cu, include_bfd, new_mac_ptr,
-                                         include_mac_end, current_file, lh,
-                                         section, section_is_gnu, is_dwz,
-                                         offset_size, include_hash);
+            dwarf_decode_macro_bytes (cu, include_bfd, new_mac_ptr,
+                          include_mac_end, current_file, lh,
+                          section, section_is_gnu, is_dwz,
+                          offset_size, include_hash);

-               htab_remove_elt (include_hash, (void *) new_mac_ptr);
-             }
+            htab_remove_elt (include_hash, (void *) new_mac_ptr);
+              }
+        }    
          }    
          break;


(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) ?

Cheers,
Romain

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