From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) by sourceware.org (Postfix) with ESMTPS id 4A0003952D8E for ; Mon, 19 Apr 2021 04:57:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4A0003952D8E Received: by mail-pg1-x535.google.com with SMTP id 31so7936203pgn.13 for ; Sun, 18 Apr 2021 21:57:44 -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; bh=y+/Kd6UxD6SoIEPYFdFY2NwEfwAHqu1raWLwP4SF0ic=; b=IJwIJi8ZYfAYyfn4KtklgvpFoirRr8AQzqLgmZTRoxilgM+3nZE3Hq+EbvgqsV+Ntp OXCkAT2HffLhPGiAbru1XjPxMJCYyRUflwRFazVhfoSqiN5WosRLir0rUQragU7rQDM2 /ru9BDnMHGbcn4GX7JC77MDTARsbqf0hzW6Yex71pFoiEfIy7WwYLIK/1ElU4XaeH5A3 S6fO5iOAtO/54QCztuM/M0CYOsSD/CRHHLMKGXmgGsH5e33fZTIOSD+uUxiPHGkGpejU lx/WqGrkFpkuJ+21E+j/TcN6stBM+PTuPXSqzLDZD40vSd4YJbYERhVJOVCeRFpBqzUl wTWA== X-Gm-Message-State: AOAM532+VDdJA4dlJ4UsQAIA9fi4bY4xoblPkolPtg0sMtPD/y1ES9jM 7e1C5EBU25F6rFmuuBvSqFkFJ/zz7O69XwnIRpg= X-Google-Smtp-Source: ABdhPJwhwXP7zZTyPv9tbhys3BmsiVJhLgwej6jdlf2A2n6eeGoADDSBXj95k4k2ImAFzlRAgq+HUN3ZHEYwgqgvhNM= X-Received: by 2002:a63:4c0e:: with SMTP id z14mr10052526pga.30.1618808263443; Sun, 18 Apr 2021 21:57:43 -0700 (PDT) MIME-Version: 1.0 References: <537840208.5089288.1618695042450.ref@mail.yahoo.com> <537840208.5089288.1618695042450@mail.yahoo.com> <95f8714b-a105-8759-dcc4-73122ee8bcf2@yahoo.de> In-Reply-To: <95f8714b-a105-8759-dcc4-73122ee8bcf2@yahoo.de> From: David Blaikie Date: Sun, 18 Apr 2021 21:57:32 -0700 Message-ID: Subject: Re: Greatly increased GDB memory and CPU usage with newest embedded ARM toolchain To: "R. Diez" Cc: "gdb@sourceware.org" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 04:57:48 -0000 4My high water mark reported my massif for the non-lto build was 197MB - most of that seems to come from decoding the macro information (dwarf_decode_macros). You could try dropping down from -g3 to -g2 to see if that helps. (I realize the linux kernel uses a bunch of macros and benefits from debug info for macros, but it'd at least help isolate the problem - might help clarify whether the lto case is related or. not) On Sun, Apr 18, 2021 at 10:02 AM R. Diez wrote: > > > [...] > > & yeah, that does seem like quite a bit of RAM usage for a relatively > > small amount of debug info. Though I'm not a regular/frequent gdb > > developer, so I don't have any particular insight there - if no one > > else chimes in, might be worth running valgrind --tool=massif to get a > > memory profile, might point to what part of gdb is using all the RAM. > > I am worried that I may not be building the toolchain and/or GDB correctly. > > Could you do the following test for me, just to confirm that you are > indeed seeing such a high memory consumption? > > Could you build GDB 10.1 for ARM? This is how I am configuring it for > cross-debugging (somewhat simplified): > > configure \ > CFLAGS="-g0 -O3 -flto=9 -march=native" \ > CXXFLAGS="-g0 -O3 -flto=9 -march=native" \ > --target=arm-none-eabi > > Maybe you want to build it without -O3 and LTO, just using the defaults. I > have been using those flags for years with previous versions without any > issues. > > Then load one of the .elf files in the attachment like this. There is no > need to have any ARM CPU available: > > ./arm-none-eabi-gdb firmware-debug-non-lto.elf > > At this point, GDB should be using less than 15 MiB of RAM. > > Now issue this GDB command: > > print StartOfUserCode > > You should see an output like this: > > $1 = {void (void)} 0x866d8 > > Did that take more than 1 second? How much RAM is your GDB using now? > > If you repeat that with firmware-release-lto.elf , how much memory is your > GDB using? Be prepared to kill it before it breaks your system though. I > normally kill it after a few seconds when it reaches 2 GiB of RAM. > > Thanks in advance, > rdiez >