From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uu2YNTXtgWCeZwAAWB0awg (envelope-from ) for ; Thu, 22 Apr 2021 17:40:05 -0400 Received: by simark.ca (Postfix, from userid 112) id CD8641F104; Thu, 22 Apr 2021 17:40:05 -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 E5B781E54D for ; Thu, 22 Apr 2021 17:40:04 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3BC373844008; Thu, 22 Apr 2021 21:40:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3BC373844008 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619127604; bh=XXH2Sita2G5cbFn4sCAyBBF7bVpSu+l/Smf8/aWZHGA=; 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=cml359D37/7kdXQGdNfdbQB8L24oAkkUrobqfN50cgQjuz1sgdDtAQlqWyxT+o8Rf ggjnZdR2UrcnlWglK3dPjTT+h61i/FhEexeAtO9Y89IHjF6U/d7cAa+LZNfKlnGW1F 0ts7WM+nBqOaW76NHt2RtPEf6/RKGZ0mDEfsrL1A= Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) by sourceware.org (Postfix) with ESMTPS id D54A63857025 for ; Thu, 22 Apr 2021 21:40:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D54A63857025 Received: by mail-qk1-x729.google.com with SMTP id d19so12186311qkk.12 for ; Thu, 22 Apr 2021 14:40:01 -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=XXH2Sita2G5cbFn4sCAyBBF7bVpSu+l/Smf8/aWZHGA=; b=Pdahkfi8Txz0uOcAkHAIkOtzxKfh6KBVNhrDCVZq/pP0QPm+IOxeCXA9eGU2ikaOSE 2kdHx7eSqawpmcjbLvb6bzl9dFAHV9q1xyMMHfFV+7y/ruUiwES028vp6WpbibyKfek8 Iv9Cg+49es1czaKV661u76JkSnAY+tEl4M2hv1IPvKpkFgBBPfq40+lrAV6kbYMpbA2M NMectYtN/iNjaeTWQe9lpv0Y5OqptZegnss7j347aDOlAwM/mOIadtswSlKtJlYQ/p65 7H1C+jGKoP0SVOKo3e+7dXPLn3OL9oK942SOFhd2Kt0nDbmKOaZ4Cdi95yillphasU5O 403g== X-Gm-Message-State: AOAM53064f0zeR9MlzE7/IKGD1Zk2aS+HciZk4/j+FCkkTKcY/UPO8cL f7yzbhlJ+hQiArgQq3g9yhZdOs9fNH0aJDA76ZCjnw== X-Google-Smtp-Source: ABdhPJy+j+EbatjwnF4khAIxLYJxTcSRoLr/wxDTbZHDf4PvGV7y4hgWRNJdA0g4rjsJRKwKKq4XtPlWQAB8ax9QTs8= X-Received: by 2002:a05:620a:e10:: with SMTP id y16mr830648qkm.375.1619127601238; Thu, 22 Apr 2021 14:40:01 -0700 (PDT) MIME-Version: 1.0 References: <20201103221306.6688-1-tom@tromey.com> <20201104105933.GA16965@blade.nx> <871rb3gryw.fsf@tromey.com> In-Reply-To: <871rb3gryw.fsf@tromey.com> Date: Thu, 22 Apr 2021 16:39:22 -0500 Message-ID: Subject: Re: [PATCH] Shrink size of dwarf2_per_cu_data To: Tom Tromey Content-Type: text/plain; charset="UTF-8" X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Christian Biesinger via Gdb-patches Reply-To: Christian Biesinger Cc: gdb-patches Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Wed, Apr 21, 2021 at 6:04 PM Tom Tromey wrote: > > >>>>> "Gary" == Gary Benson writes: > > Gary> Tom Tromey wrote: > >> I noticed some holes in struct dwarf2_per_cu_data. This patch > >> rearranges the type slightly, and shrinks the size of some fields. > >> This reduces it from 136 bytes to 112 bytes (on x86-64). > > Gary> Nice. Though I'd assumed the compiler would do this. > > C and C++ compilers can't generally do this, though other languages like > Rust and Ada do allow it. > > >> I also reduced the size of the DWARF "version" fields in a couple of > >> spots. It seemed needless to use a short to hold a value that > >> ranges from 2 to 5, and this also helped the goal of shrinking > >> dwarf2_per_cu_data. > > Gary> There's other things in there if you were going that way, e.g.: > > Gary> unsigned char addr_size; > Gary> unsigned char signed_addr_p; > Gary> sect_offset abbrev_sect_off; > > Gary> /* Size of file offsets; either 4 or 8. */ > Gary> unsigned int offset_size; > > Gary> /* Size of the length field; either 4 or 12. */ > Gary> unsigned int initial_length_size; > > Gary> I presume you'd need to lose 8 whole bytes to shrink the struct > Gary> further, so marking these as <8bit values probably wouldn't help > Gary> any, but maybe it's worth it? > > I looked at this, and it doesn't remove enough space to help. > Might still be worth doing for clarity, I dunno. > > Gary> How many CUs does something big > Gary> have? > > gdb has 1197 as of today, but IMO it is moderately-sized at best. > I don't have anything really big that's convenient to check. I tried to approximate the number of CUs that Chrome has (Linux debug build): $ objdump -g chrome | grep 'Compilation Unit' | wc -l 9233 Plus the parts that are in shared libraries: $ find -name \*.so | xargs -n 1 objdump -g | grep 'Compilation Unit' | wc -l 57942 I'm not sure if all the .so files get loaded at the same time, so it may be a bit fewer in practice. Of course this does not include any CUs that may come from debug symbols for system libraries. Is there a gdb command that could tell me the exact number? Christian