From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by sourceware.org (Postfix) with ESMTPS id 666623857419 for ; Mon, 21 Jun 2021 12:49:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 666623857419 Received: by mail-pg1-x534.google.com with SMTP id i34so8443392pgl.9 for ; Mon, 21 Jun 2021 05:49:40 -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=w64aH1VTev9ac3wygiTmAL9yuGNN/U1SZgOTk44plNE=; b=Jyo/Odi2sfmoCQ5Wr1iEE3XCOlXSzfiimaleHL7CrHWNuFwMKrdv2XTZA7c+zgZ/NL sAEID+A5QQZN0d+OHUs4SPSDDRvfPkckgAwiDK1pp8B9CmpdDx2T5jtsAo7tjmCgGk8y y6EaLCdLlRatC24HyUpn2uz8wQ4MBe+i5TpDPvgkqWCmnpUZi7i5I6LS4e18zp61d0ZK vxeYrDHSWdGDxGYn3ZKTLedTCxH5cQrJdvHEiIoe4rdCXJSC3jz5CY3ttxcZuu+8alqr shqSR5YGE2s+KZAuq6gGVCgwIMi28eRqphsQjR43zGbI8fhHqyGpSXWezIq5UyrEqe/8 v4/g== X-Gm-Message-State: AOAM530J2MeWcvl+iMTd9U91Vd7fudbXLIT5MvCKCPsfTuvniRW+fwBm rok+xgzaVzCqCHOGRqR+nM7ICF/Dc/206Pd5IxM= X-Google-Smtp-Source: ABdhPJxaEGSqJdMuhb3Jqx15ZpCU0mrPTTW1gcyjPkRLHUwgSsOvkoKaGRL6z49z2DZuRpM+Gpwmk2xFGx6NA30uMds= X-Received: by 2002:a63:180c:: with SMTP id y12mr24383030pgl.180.1624279779608; Mon, 21 Jun 2021 05:49:39 -0700 (PDT) MIME-Version: 1.0 References: <20210620233620.391576-1-hjl.tools@gmail.com> <20210620233620.391576-3-hjl.tools@gmail.com> <875yy7mzmr.fsf@oldenburg.str.redhat.com> In-Reply-To: <875yy7mzmr.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Mon, 21 Jun 2021 05:49:03 -0700 Message-ID: Subject: Re: [PATCH 2/4] Check -z single-global-definition and -fsingle-global-definition To: Florian Weimer Cc: "H.J. Lu via Libc-alpha" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3030.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jun 2021 12:49:44 -0000 On Mon, Jun 21, 2021 at 12:43 AM Florian Weimer wrote: > > * H. J. Lu via Libc-alpha: > > > 1. Check linker support for -z single-global-definition. If > > GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION is set on any input > > relocatable files: > > a. Don't generate copy relocations. > > b. Turn off extern_protected_data. > > c. Treate reference to protected symbols with single global definition > > as local. > > d. Set GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION on output. > > e. Add -z [no]single-global-definition to control single global > > definition. > > 2. Check compiler support for -fsingle-global-definition: > > a. Generate a single global definition marker in relocatable objects. > > i. Always use GOT to access undefined data and function symbols, > > including in PIE and non-PIE. These will avoid copy relocations in > > executables. > > ii. This is compatible with existing executables and shared libraries. > > b. In executable and shared library, bind symbols with the STV_PROTECTED > > visibility locally: > > i. The address of data symbol is the address of data body. > > ii. For systems without function descriptor, the function pointer is > > the address of function body. > > iii. The resulting shared libraries may not be incompatible with > > executables which have copy relocations on protected symbols. > > > > Size comparison of non-PIE builds with GCC 12 -O2: > > > > 1. On x86-64: > > text data bss dec hex filename > > 190218 9672 416 200306 30e72 ld.so (original) > > 190258 9336 416 200010 30d4a ld.so (-fsingle-global-definition) > > 1917384 20232 52424 1990040 1e5d98 libc.so (original) > > 1919946 20240 52432 1992618 1e67aa libc.so (-fsingle-global-definition) > > 261734 10339 744 272817 429b1 localedef (original) > > 233084 41734 648 275466 4340a localedef (-fsingle-global-definition) > > I must say these numbers do not make sense to me. Why do libc.so and > localedef data sizes increase with -fsingle-global-definition? Fewer I haven't investigated them in detail yet. My main purposes were to check if anything breaks. > copy relocations should *reduce* data size on both sides. localedef > would have to have nearly 4,000 data relocations to account for the size > increase. And shouldn't the GOT overlap with BSS anyway (so not even > show up in the data column)? I will take a closer look. > And I don't think we can build glibc with -fsingle-global-definition > anyway because it would be an ABI break. Correct. > > --- > > configure | 73 +++++++++++++++++++++++++++++++++++++++++++++++++++- > > configure.ac | 37 ++++++++++++++++++++++++++ > > 2 files changed, 109 insertions(+), 1 deletion(-) > > > > diff --git a/configure b/configure > > index 9619c10991..5844dad68f 100755 > > --- a/configure > > +++ b/configure > > @@ -732,6 +732,7 @@ infodir > > docdir > > oldincludedir > > includedir > > +runstatedir > > localstatedir > > sharedstatedir > > sysconfdir > > Please regenerate with an unpatched autoconf. > Will do. Thanks. -- H.J.