From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 2948E386FC01 for ; Mon, 19 Apr 2021 01:07:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2948E386FC01 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 13J17cKb002990 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 18 Apr 2021 21:07:43 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13J17cKb002990 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 375141E54D; Sun, 18 Apr 2021 21:07:38 -0400 (EDT) Subject: Re: Greatly increased GDB memory and CPU usage with newest embedded ARM toolchain To: "R. Diez" , "gdb@sourceware.org" References: <537840208.5089288.1618695042450.ref@mail.yahoo.com> <537840208.5089288.1618695042450@mail.yahoo.com> From: Simon Marchi Message-ID: <5a3b0f58-09ad-2199-5e35-8467554db890@polymtl.ca> Date: Sun, 18 Apr 2021 21:07:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <537840208.5089288.1618695042450@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 19 Apr 2021 01:07:38 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2021 01:07:54 -0000 On 2021-04-17 5:30 p.m., R. Diez via Gdb wrote: > Hi all: > > 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 information, see this comment of mine: > > https://sourceware.org/bugzilla/show_bug.cgi?id=23710#c18 > > I noticed that GDB is now using much more RAM than before, and not just for LTO builds, which is what that bug report was about. > > I just tried with this open-source firmware of mine: > > https://github.com/rdiez/JtagDue > > 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. I don't have anything useful to add. But I was wondering if you could share a set of commands to configure / build your project exactly like you configure / build it yourself. And then a set of GDB commands to do something where you experience such a slowdown. We could start by trying to reproduce it, that would be a good first step to investigate it. To have an isolated environment that we can reproduce (make sure GDB doesn't load some .gdbinit file), start your GDB with -nx. > The debug information is not compressed. > > 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. Is that not too much for this smallish project? I never really paid attention, so I can't tell. I have noticed some strange slowdowns recently when I debug GDB with GDB (probably a bit bigger than your program). For example, when I type "backtrace", there is sometimes a noticeable pause between the display of some frames. > I tried a release build, compiled with LTO, and GDB became unresponsive in the same situation. I killed GDB manually when it got to consume over 2 GiB of RAM, because I have had such a misbehaving GDB freeze my Ubuntu 20.04.2, not even the mouse was moving. I do not have swap, so I would have expected the Out of Memory Killer to kick in, but it did not. I had to physically switch my computer off. Yep, that's really bad :(. > Before I spend more time investigating this issue: is this a known problem? > > The bug report mentioned above seems to suggest that there is something foul in this area, but there does not seem to be much interest in the past months. The trouble is, I am seeing now pauses and high memory usage even in non-LTO builds. GDB is still usable, but it is becoming annoying. > > I have been using this toolchain for many years, and I am getting this kind of problem with GDB only relatively recently. Do you have a version in mind that you remember worked better? We could compare the profiling numbers between the two versions. Simon