From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id 9561F3857830 for ; Sun, 18 Apr 2021 15:41:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9561F3857830 Received: by mail-pg1-x52b.google.com with SMTP id m12so1798140pgr.9 for ; Sun, 18 Apr 2021 08:41:16 -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=u2CteUCH3r3NNvGknGIKnT65oaJUc80+v7o8NPfIQzk=; b=FItozrJonjOK4eRJ2JbB4qhtSO0xaxqGBI60R979Y8bd740cljeINJu8eodfg+Epb1 ZDjb856cj0H1y+QofOUIiOZriysn2qcQBH30fAaFLdoVKOR05jIp9KnJIGHD34k7QxKb LXouUXSuvgjHDWzfAHxczcxxsyIJg/fRdd41lkdnFk2hfZLSo7nKKED3DhvD2PsWmFT+ WYJ8t3PvGaoNSksjIaJ281yODUpeDap89yk23KVfVdAPpz6NasadP3efmq4uZN6wixgL RFwXgmjIMQhSHp3CKLv8CDvLtVcvCMzrMw8y5ERrdMZaEq6gvl/5MIqnFP6DKc/87HYz YRmg== X-Gm-Message-State: AOAM533xauaMHkd8nwwJmS3Xv9lmlzKHcasLs3HVhPdrOU8UR7qkMeUu V+VrnGsUAy0kyEEoqI1gn5MJkTdvLeO+iKugAwysqhbU X-Google-Smtp-Source: ABdhPJxQ8jPLVI4INNrBOf4L/vCfX6Qx8FBFixcsxeCIBiEzlM2gJ3glZF4ngzGp7Kv35aHwUI8Dgq9W0GXx0GneKCw= X-Received: by 2002:aa7:9496:0:b029:252:f269:ffa3 with SMTP id z22-20020aa794960000b0290252f269ffa3mr16189137pfk.30.1618760475706; Sun, 18 Apr 2021 08:41:15 -0700 (PDT) MIME-Version: 1.0 References: <537840208.5089288.1618695042450.ref@mail.yahoo.com> <537840208.5089288.1618695042450@mail.yahoo.com> In-Reply-To: From: David Blaikie Date: Sun, 18 Apr 2021 08:41:04 -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" X-Spam-Status: No, score=-1.2 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: Sun, 18 Apr 2021 15:41:18 -0000 Yeah, that checks out then. (you can also confirm that SHF_COMPRESSED is not used by readelf -S or llvm-readelf -S and checking for the "C" value in the Flags column) & 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. On Sun, Apr 18, 2021 at 1:16 AM R. Diez wrote: > > > >> 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) > > > I do not know about SHF_COMPRESSED. > > I checked with: > > $ ./arm-none-eabi-ld --help > > [...] > --compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi] > Compress DWARF debug sections using zlib > Default: none > [...] > > > I did not quite trust the "Default: none" statement, so I tested in the past by passing the following flag: > > -Wl,--compress-debug-sections=zlib > > And the resulting elf file was less than half the size. > > That is how I assume that the debug information is not being compressed. > > I am not compressing because for such a little project it is not worth it. > > Regards, > rdiez