Bug 1150787 - gdb with flto debug info
gdb with flto debug info
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Tom de Vries
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-14 15:17 UTC by Tom de Vries
Modified: 2019-09-17 08:51 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2019-09-14 15:17:59 UTC
We've switched to build factory packages with -flto, but the flto support in the gdb is not well tested. So, people can run into issues when debugging packages.

We could add flto as a testing axis, and/or at least do an effort to cleanup the most serious failures.
Comment 1 Richard Biener 2019-09-17 06:42:44 UTC
The most annoying thing is the slowness of gdb and the amount of memory it uses.

I'll see to repeat an experiment from the GCC 8 times and use a LTO built
GCC for debugging in the next days.
Comment 2 Richard Biener 2019-09-17 08:11:02 UTC
So, configure/build GCC like

obj> CFLAGS="-g -flto" CXXFLAGS="-g -flto" /tmp/trunk/configure --disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib --disable-libstdcxx-pch
obj> make -j all-gcc CFLAGS="-g -flto" CXXFLAGS="-g -flto"

and then figure the time and memory it takes to do

obj/gcc> gdb --args ./cc1 -quiet t.c
obj/gcc> b 'value_range_base::intersect_helper'
obj/gcc> run
<breakpoint>
obj/gcc> p debug_val<TAB><TAB>

(hangs)

23609 rguenth+  20   0 2371008 2.196g 125928 R 100.0 7.008   4:06.89 gdb

otherwise debugging works fine as far as I can see, it's really just gdb
being slow and memory hungry (likely because of its internal data structures
duplicating all the sharing in the original dwarf via abstract origins and
imports).
Comment 3 Richard Biener 2019-09-17 08:51:12 UTC
Overhead       Samples  Command  Shared Object        Symbol                   ◆
  45.79%        202446  gdb      gdb                  [.] symbol_natural_name  ▒
  10.66%         47112  gdb      gdb                  [.] skip_ws              ▒
   7.01%         30976  gdb      gdb                  [.] iterator_next_hashed ▒
   5.32%         23530  gdb      gdb                  [.] strncmp_iw_with_mode ▒
   2.60%         11506  gdb      libc-2.26.so         [.] isspace              ▒
   2.50%         11046  gdb      gdb                  [.] completion_list_add_n

  /* Add completions for all currently loaded symbol tables.  */
  for (objfile *objfile : current_program_space->objfiles ())
    {
      for (compunit_symtab *cust : objfile->compunits ())
        add_symtab_completions (cust, tracker, mode, lookup_name,
                                sym_text, word, code);
    }

is taking up all the time.  We visit 532 compunit_symtabs.

This might be an artifact on how LTO builds CUs which has a single CU
per LTRANS unit that imports all "source CUs" (from compile-time)
that end up being used, increasing the search space considerably(?).

For symbol lookup I'd expect gdb to not use the context of the
instantiation of value_range_base::intersect_helper (the LTRANS CU)
but the CU of its abstract instance (the "source" CU).

Basically how gdb would operate when in the context of an inlined
function body though that situation probably does't reflect the LTO
one 1:1.  But think of GCC placing concrete instances in special
CUs away from their abstract and inline instances.

All that said, the TAB-completion issue makes debugging unusable
(a single completion takes a few minutes), you have to really avoid
doing this... (also seems you cannot interrupt it).