From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 97393388CC3E; Thu, 16 Jul 2020 12:51:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 97393388CC3E From: "rdiezmail-binutils at yahoo dot de" To: gdb-prs@sourceware.org Subject: [Bug gdb/23710] gdb is slow and memory hungry consuming debug generated with LTO by GCC Date: Thu, 16 Jul 2020 12:51:04 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: 8.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rdiezmail-binutils at yahoo dot de X-Bugzilla-Status: NEW 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: Message-ID: In-Reply-To: References: 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: Thu, 16 Jul 2020 12:51:04 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D23710 --- Comment #16 from rdiezmail-binutils at yahoo dot de --- I develop a relative small firmware for ARM Cortex-M4F since some years ago, and I did not notice any slowdown up to and including GCC 8.3 and GDB 8.3. In the past months, I upgraded my toolchain to GCC 9.3 and GDB 9.2, and the= n I started noticing a big slowdown of several seconds on the first "hbreak myfunction" command. I guess that is the first time that GDB loads the symb= ols. The slowdown only happens with release builds compiled with LTO. With debug builds (with asserts and without LTO), GDB start-up is instantaneous. These are the GDB RAM usage stats I collected: Debug firmware build: VSZ: 101 MiB, RSS 33 MiB. Release firmware build: VSZ: 430 MiB, RSS 362 MiB. I do not understand why this difference, because it is exactly the same firmware. The LTO build is smaller and faster, but it has the same symbols = (or less, because asserts etc. are per "#ifndef NDEBUG" no longer there). I hope the patches above fix this issue. But I would say that the GDB's handling of LTO builds would not need a 30 % speed increase, but more like = a 10 fold improvement. --=20 You are receiving this mail because: You are on the CC list for the bug.=