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 C0FE538582BE for ; Mon, 27 Jun 2022 19:56:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0FE538582BE Received: by mail-pg1-x534.google.com with SMTP id z14so10107848pgh.0 for ; Mon, 27 Jun 2022 12:56:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=RtqVa/UA4F88+4yoD9/wM/k1Z6KMe7X3mQxePQl+wbw=; b=OE49l8i7bmeu0Fg3ROyYwoobP99qh2aisyKiAlgiCUJhQrXyBhkj/gL77Nyhm6FmRu SgVioHrOhjgqd9LV7mBGUn76IrL6BGjIT/U12qzUaxrVINChLgY6N2p7LH9hOGeQEuih rUHKXoRX3yvX3r6JWg1RuTQlfoUPr0sXM8Ay+/XLlvcKS8qxgGUuzDUPqbkg9HfNNMwb bSn68bAOBb938buTkFZZVUhbqoMKkditk3zLgycMkWugPqOSclZnx+n7w1T3GiqSTti8 jntZFpNi384O9XvhSWwfQqaTCSN7KFDvzuN1GNU6B3Pwyjcyj/qqQoO69mBIPaUf7hHE NtFg== X-Gm-Message-State: AJIora9sFKJLtfF76xyW5Z1q9KevTW3+pDO8p5kHRtMjRiBmGYy4HQY8 U6xt+bwudWPfJLs9isovWu2TRhIiPcReXw== X-Google-Smtp-Source: AGRyM1t/YYYXIVJq1+1p6CYzzzVXrBKC8wVAf3ZmPjogjS1oAPQPkb1+DN++1GUmoA5nulFrB5ZITQ== X-Received: by 2002:aa7:8b50:0:b0:527:b2c0:bac0 with SMTP id i16-20020aa78b50000000b00527b2c0bac0mr725817pfd.37.1656359769759; Mon, 27 Jun 2022 12:56:09 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:dc6a:d216:ff60:5a40]) by smtp.gmail.com with ESMTPSA id a23-20020a17090a6d9700b001eccb13dfb0sm10090484pjk.4.2022.06.27.12.56.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Jun 2022 12:56:09 -0700 (PDT) Date: Mon, 27 Jun 2022 12:56:06 -0700 From: Fangrui Song To: Florian Weimer Cc: Fangrui Song via Libc-alpha Subject: Re: [PATCH] Makerules: Remove no-op -Wl,-d when linking libc_pic.os Message-ID: <20220627195606.2bbe7kzbmztzsdoi@google.com> References: <20220626184025.553459-1-maskray@google.com> <87tu87nn4y.fsf@mid.deneb.enyo.de> <20220626222936.56qfdvvtbv4u7gz2@google.com> <871qva353f.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <871qva353f.fsf@mid.deneb.enyo.de> X-Spam-Status: No, score=-19.0 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE, URIBL_BLACK, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 27 Jun 2022 19:56:12 -0000 On 2022-06-27, Florian Weimer wrote: >* Fangrui Song: > >>>Do you know what the .gnu.glibc-stub.* processing processing refers >>>to? >> >> [a] Just few lines below, there is >> >> # Generate a list of -R options to excise .gnu.glibc-stub.* sections. >> >> The idea is to create libc_pic.os from libc_pic.a, strip .gnu.glibc-stub.*, then link libc_pic.os.clean into libc.so. >> >> Technically the relocatable link can be omitted. We can change `build-shlib` >> to link -Wl,--whole-archive libc_pic.a -Wl,--no-whole-archive instead. objcopy -R works on an archive for >> a long time. I am unsure whether the 1990+ objcopy supports archives. >> But at a first glance I do not find a good place to insert -Wl,--whole-archive into build-shlib... > >For linking libc.so, we can list the objects directly, then we don't >need -Wl,--whole-archive. > >For linking ld.so, we do not use -Wl,--whole-archive because we >actually want to link a subset. I was under the impression that we >rebuild objects for inclusion into ld.so, so I'm rather puzzled that >we need this. This plan looks good to me. Removing the relocatable link for libc_pic.os will make incremental build slightly faster. >> [b] Around $(objpfx)stubs: $(objs-for-stubs), we can see that >> .gnu.glibc-stub.* is to generate */stubs files and finally testroot.root/$prefix/include/gnu/stubs-64.h >> >> % cat testroot.root/tmp/glibc/lld/include/gnu/stubs-64.h >> /* This file is automatically generated. >> It defines a symbol `__stub_FUNCTION' for each function >> in the C library which is a stub, meaning it will fail >> every time called, usually setting errno to ENOSYS. */ >> >> #ifdef _LIBC >> #error Applications may not define the macro _LIBC >> #endif >> >> #define __stub___compat_bdflush >> #define __stub_chflags >> #define __stub_fchflags >> #define __stub_gtty >> #define __stub_revoke >> #define __stub_setlogin >> #define __stub_sigreturn >> #define __stub_stty > >Those warning sections must propagate into libc.so, so I think we >could parse that and the generate header from it. The final libc.so does not want .gnu.glibc-stub.* sections. The current build steps look like: 1. ar cruv libc_pic.a `cat csu/stamp.os iconv/stamp.os ...` 2. build libc_pic.os libc_pic.a 3. build libc_pic.os.clean from libc_pic.os 4. build libc.so from libc_pic.os.clean csu/abi-note.o elf/interp.os elf/ld.so ... I think ideally 2 and 3 can be omitted. It seems like you want to omit libc_pic.a as well? That looks good to me. stubs files can be either generated from .os files (in step 1) or libc.so (then a separate strip command on libc.so is needed).