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