From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id AFB2A3857804 for ; Sat, 17 Apr 2021 22:15:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AFB2A3857804 Received: by mail-pl1-x62b.google.com with SMTP id z22so10654279plo.3 for ; Sat, 17 Apr 2021 15:15:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9nAYpfn1kPMCmCkiPD3+uotKk1tnpurDtH+9Fd/b8WQ=; b=cb37+S1REMHqWzn5ZHFoAU8NkNFWd4JD1+Dn1jJLtLX0ojZBIWZSm/mlOu4zLL58m2 KI5XlMk0zlHYoGMPPgQDBy6bLqH7E6Ahf9jpaiN7qVBSj+8PKup1+dFRp0Vqfq+oVpSm rA1BnDFnbtZWXJONU6neVGWhyFiNJhvX2NJyRh6qpJLRkx85PxysKB1hif24J9xiXBwZ 5ufH0gmYQ0TAMKzCQFJaOQxy7E4IrDYUe16DZLUZnoxjSwfp7ExKM7rTEmropR+TMiWi tZ9P5DaeEZYuFZXGcb/2HyHMi3tLzDQHh2xIrgK24ABQJvMfW4oAa6aaRw1CF0CC1j7P CyuA== X-Gm-Message-State: AOAM533c8dU8mEEXeUcQ9JPdUS+HU6kNU5Ni5mctb4u+A82kfTxhgIXK wA16+84kjAmNH5QFcoJu15llE/AeaRTfqTmdl8/nQ7A3g6A= X-Google-Smtp-Source: ABdhPJzJOHLt7Kfk6Pq2cBwi/5VunAMYUaw8yNojo+Ayd+BhTs0ct+xTg6PPSL7L4rfYJPxSEx99oXPwgVk3cxMrclc= X-Received: by 2002:a17:902:6946:b029:e9:4dcc:9966 with SMTP id k6-20020a1709026946b02900e94dcc9966mr16026534plt.6.1618697719841; Sat, 17 Apr 2021 15:15:19 -0700 (PDT) MIME-Version: 1.0 References: <537840208.5089288.1618695042450.ref@mail.yahoo.com> <537840208.5089288.1618695042450@mail.yahoo.com> In-Reply-To: <537840208.5089288.1618695042450@mail.yahoo.com> From: David Blaikie Date: Sat, 17 Apr 2021 15:15:08 -0700 Message-ID: Subject: Re: Greatly increased GDB memory and CPU usage with newest embedded ARM toolchain To: "R. Diez" Cc: "gdb@sourceware.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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: Sat, 17 Apr 2021 22:15:22 -0000 > The debug information is not compressed. How are you determining that ^ ? (I ask, because historically compressed debug info was opt-in and used a section name mangling (.zdebug_*) to notate compressed debug sections - but recent versions of GCC have started compressing by default and using an ELF section flag (SHF_COMPRESSED) without section name mangling (so dumping section names would not be enough to determine whether compressed debug info was used) But, yeah, that does seem like a lot of work, for all of 76kB of non-debug executable... On Sat, Apr 17, 2021 at 3:01 PM 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=3D23710#c18 > > I noticed that GDB is now using much more RAM than before, and not just f= or 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 i= t is debug information, because the firmware.bin file only weighs 76 kB. > > The debug information is not compressed. > > When GDB needs to load the symbols, because you are touching some C++ sou= rce code, there is a noticeable pause, and GDB uses 385 MiB of RAM. Is that= not too much for this smallish project? > > I tried a release build, compiled with LTO, and GDB became unresponsive i= n the same situation. I killed GDB manually when it got to consume over 2 G= iB 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 expe= cted the Out of Memory Killer to kick in, but it did not. I had to physical= ly switch my computer off. > > Before I spend more time investigating this issue: is this a known proble= m? > > The bug report mentioned above seems to suggest that there is something f= oul in this area, but there does not seem to be much interest in the past m= onths. 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 ki= nd of problem with GDB only relatively recently. > > Best regards, > rdiez