From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id liQDCSFTfGC9VgAAWB0awg (envelope-from ) for ; Sun, 18 Apr 2021 11:41:21 -0400 Received: by simark.ca (Postfix, from userid 112) id 17E751F104; Sun, 18 Apr 2021 11:41:21 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 4EEF11E783 for ; Sun, 18 Apr 2021 11:41:20 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3B2FC3857830; Sun, 18 Apr 2021 15:41:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B2FC3857830 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1618760479; bh=u2CteUCH3r3NNvGknGIKnT65oaJUc80+v7o8NPfIQzk=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Bhp5/iY2Bqr9310RF/jllC44IdoQpie+6dAzt6RoJaFTAB8X7tUfV6R9PLyt86ntH OJtEfSpcFrmlUP+t1qGV8oV4Vnxzee7MW5BRvYQ2p3AjJZHqSvBe44V8tavMQwd4Hj n7I7+dht8CwPO3AvqRvTV+y4T9VNVtZe1/ocmm9w= 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: 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" Content-Type: text/plain; charset="UTF-8" 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: , From: David Blaikie via Gdb Reply-To: David Blaikie Cc: "gdb@sourceware.org" Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" 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