public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Blaikie <dblaikie@gmail.com>
To: "R. Diez" <rdiezmail-binutils@yahoo.de>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Greatly increased GDB memory and CPU usage with newest embedded ARM toolchain
Date: Sat, 17 Apr 2021 15:15:08 -0700	[thread overview]
Message-ID: <CAENS6EuFMSpJ-+0Kk7nj6JS_WH7o4uApEb5-9TtxAMwdYsw7Ag@mail.gmail.com> (raw)
In-Reply-To: <537840208.5089288.1618695042450@mail.yahoo.com>

> 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 <gdb@sourceware.org> 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.
>
> 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 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.
>
> 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.
>
> Best regards,
>   rdiez

  reply	other threads:[~2021-04-17 22:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <537840208.5089288.1618695042450.ref@mail.yahoo.com>
2021-04-17 21:30 ` R. Diez
2021-04-17 22:15   ` David Blaikie [this message]
2021-04-18  8:16     ` R. Diez
2021-04-18 15:41       ` David Blaikie
     [not found]         ` <95f8714b-a105-8759-dcc4-73122ee8bcf2@yahoo.de>
2021-04-19  4:57           ` David Blaikie
2021-04-19  5:10             ` David Blaikie
2021-04-19 16:08               ` R. Diez
2021-04-19  7:06             ` R. Diez
2021-04-19  1:07   ` Simon Marchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAENS6EuFMSpJ-+0Kk7nj6JS_WH7o4uApEb5-9TtxAMwdYsw7Ag@mail.gmail.com \
    --to=dblaikie@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=rdiezmail-binutils@yahoo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).