[Bug gdb/29702] Huge slowdown just after loading thread DWARF data when hitting breakpoints (gdb in MCUXpresso / Eclipse)

["nickpelling at nickpelling dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #3 from Nick Pelling <nickpelling at nickpelling dot com> ---
Thanks very much Tom & Simon, I now have some additional debug info to share.

I tried using "maint set dwarf max-cache-age 0" but this made no noticeable
difference (alas). I also tried "maintenance expand-symtabs", along with "set
debug symfile on" and "set debug symbol-lookup 10", but these yielded no extra
information.

I did get some more information using "set debug symtab-create", e.g.

set debug symtab-create 10
set debug dwarf-read 10
set debug dwarf-line 10

This showed that the unexpected long pause for a given thread is happening
after the final "Created symtab" message and before "Done expanding CU at
offset":

794,918 &"Created symtab 0x213880c8 for module C:\\[File
Path]\\repos\\platformmaster\\FreeRTOSLib\\lwip\\src\\include/lwip/prot/udp.h.\n"
794,918 &"Created symtab 0x213880e8 for module
../../FreeRTOSLib/libcoap/include/coap2/utlist.h.\n"
800,521 &"Done expanding CU at offset 0x14dffb\n"

The final printf here is in process_queues(), so the code seems to be inside
process_full_comp_unit(), i.e. processing the CU's sequence of dwarf tokens.

Similarly, it looks as though the code is exiting dwarf_decode_lines() before
the slowdown is happening: which seems to be right at the end of the code
parsing the DW_AT_stmt_list token.

Using "set debug dwarf-die 10" causes the dwarf tokens in the die to be printed
out (a little further up the gdb trace). The final two dwarf tokens in each of
the modules appear to be (for example):

772,637 &"    DW_AT_stmt_list (DW_FORM_sec_offset) section offset: 206677\n"
772,637 &"    DW_AT_GNU_macros (DW_FORM_sec_offset) section offset: 289465\n"

Hence I'm now wondering if there might actually be something malformed in the
data being emitted by gcc following the DW_AT_GNU_macros dwarf token that is
causing the dwarf_decode_macros() code to get subtly borked or confused.

Unfortunately, there doesn't seem to be (unless I'm missing something obvious)
a single line of debug trace in all the gdb macro-processing code, so I'm not
getting a lot of trace assistance from that. :-(

Are there any known issues to do with gcc and parsing the DW_AT_GNU_macros
token section that might be triggering an issue here?

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