From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 3BECF3858012; Mon, 19 Apr 2021 16:03:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3BECF3858012 From: "rdiezmail-binutils at yahoo dot de" To: gdb-prs@sourceware.org Subject: [Bug gdb/27754] New: Excessive CPU load and memory usage with -g3 debug info Date: Mon, 19 Apr 2021 16:03:26 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 10.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rdiezmail-binutils at yahoo dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 16:03:27 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D27754 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=3D13381&action=3Ded= it Debug non-LTO firmware I recently upgraded my cross-compilation toolchain for ARM Cortex-M4F to th= ese 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 relea= se 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 lo= nger pauses. For the release build (LTO): GDB starts using 100 % CPU time for a long tim= e, 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 toolcha= in 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, l= ike 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 wi= th: configure --target=3Darm-none-eabi Then load one of the .elf files in the attachment like this. There is no ne= ed 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 =3D {void (void)} 0x866d8 =20 Now you can check GDB's memory usage. The release build (with LTO) is the one that shows a really massive memory usage. --=20 You are receiving this mail because: You are on the CC list for the bug.=