[Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC

["jsm28 at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=23710

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu.org

--- Comment #24 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
I've observed a case of GDB slowness on LTO code, still present with current
GDB (testing here with GDB as of commit
2d9cf99d9a6c701de912d3e95ea3ffa134af4c62), that looks a bit different from the
cases discussed here.

The customer test case has about 10 MB of text and about 1 GB of debug info in
the main C++ application (there are also lots of shared libraries involved). 
Using GDB to examine a core dump (with about 300 threads), either "info
threads" or "thread apply all bt" is both very slow on a binary built with LTO
(maybe 10 times slower than on a non-LTO binary) and consumes much more memory.

For the LTO binary and core dump, GDB loads the debug info for many more
compilation units than in the non-LTO case, resulting in many more DIEs being
loaded, process_die being called many more times (a factor of about 10) and
much more time being spent in it (a large proportion of execution time in the
LTO case is spent in process_die and its children).

The key difference in the debug info in the LTO and non-LTO cases that causes
this is references from the debug info for one CU to the debug info for another
CU, as handled by follow_die_offset. In the non-LTO case these don't occur at
all. In the LTO case, there are many such references - the greatest proportion
are DW_TAG_subprogram, but also various others such as DW_TAG_namespace and
DW_TAG_variable.

The key call is in follow_die_offset:

      /* If necessary, add it to the queue and load its DIEs.

         Even if maybe_queue_comp_unit doesn't require us to load the CU's
DIEs,
         it doesn't mean they are currently loaded.  Since we require them
         to be loaded, we must check for ourselves.  */
      if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->per_cu->lang)
          || per_objfile->get_cu (per_cu) == nullptr)
        load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu),
                             false, cu->per_cu->lang);

This call to load_full_comp_unit gets executed 9960 times in the LTO case, but
not at all in the non-LTO case. The other call to load_full_comp_unit that gets
executed is the one from load_cu (201 times in the non-LTO case, 150 in the LTO
case). So the DIEs from many more CUs are loaded in the LTO case. Then
process_full_comp_unit calls process_die 2250 times in the LTO case but only
186 times in the non-LTO case (and that recurses down to process all the DIEs
in the CU).

The underlying issue here looks like GDB's strategy of loading all the DIEs
from any CU referenced by the debug info from a CU it's loading debug info
from, rather than somehow e.g. only selectively loading the DIEs it needs for
the particular backtrace being printed.

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