[Bug gdb/27754] New: Excessive CPU load and memory usage with -g3 debug info

["rdiezmail-binutils at yahoo dot de" <sourceware-bugzilla@sourceware.org>]

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

            Bug ID: 27754
           Summary: Excessive CPU load and memory usage with -g3 debug
                    info
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: rdiezmail-binutils at yahoo dot de
  Target Milestone: ---

Created attachment 13381
  --> https://sourceware.org/bugzilla/attachment.cgi?id=13381&action=edit
Debug non-LTO firmware

I recently upgraded my cross-compilation toolchain for ARM Cortex-M4F to these
component versions:

  Binutils 2.36.1
  GCC 10.3
  GDB 10.1

For more details, this is the project I am using. It has both a makefile to
build the cross-compilation toolchain, and the firmware I am building with it:

https://github.com/rdiez/JtagDue

I noticed that GDB is now using much more RAM than before, and not just for LTO
builds.

For a debug build (non LTO), firmware.elf weighs around 1.5 MB. Most of it is
debug information, because the firmware.bin file only weighs 76 kB. A release
build (with LTO) has similar sizes.

For the debug build (non LTO): When GDB needs to load the symbols, because you
are touching some C++ source code, there is a noticeable pause, and GDB uses
385 MiB of RAM. That is already too much for this smallish project. I have
another, bigger firmware, where using GDB is becoming a pain, due to the longer
pauses.

For the release build (LTO): GDB starts using 100 % CPU time for a long time,
and memory usage reaches 5 GiB.

I got confirmation about this excessive CPU load and memory usage in the GDB
mailing list. The start of the thread is:

Greatly increased GDB memory and CPU usage with newest embedded ARM toolchain
https://sourceware.org/pipermail/gdb/2021-April/049379.html

Reducing the debug information level when compiling with GCC from -g3 to -g2
fixes the problem, at the expense of the extra information that -g3 adds, like
preprocessor macros .

I am attaching 2 .elf files to this bug built with -g3, so that you can
reproduce the problem at leisure. You need to build a cross-debugger GDB with:

configure --target=arm-none-eabi

Then load one of the .elf files in the attachment like this. There is no need
to have any ARM CPU available:

./arm-none-eabi-gdb firmware-release-lto.elf

Now issue this GDB command:

print StartOfUserCode

You should see an output like this:

$1 = {void (void)} 0x866d8 <StartOfUserCode()> 

Now you can check GDB's memory usage.

The release build (with LTO) is the one that shows a really massive memory
usage.

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