From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by sourceware.org (Postfix) with ESMTPS id D0CB43858C53 for ; Thu, 14 Apr 2022 03:43:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D0CB43858C53 Received: by mail-pl1-x634.google.com with SMTP id n8so3666246plh.1 for ; Wed, 13 Apr 2022 20:43:52 -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=OucP+YVT0fOY94wuM6EJyCZeAgfbJs1pMcscIWFvHyM=; b=UV1X21cN0u5dE7hS2kvDI6ILXkd5odLRuRRB3IJt1YxAPYqypiDOGBoQXJAJoa5c6a tcC0W1E6KavwTbk6AgvFguLHTNiABL548Do8aWsRpBpMVo9cUC8w2FN3l3jNSaorwv9D FzxImvXXXkokx+yKW8wfNFwr5juk3mBkBNhBiYfr/aHgplhwetR0aDwa/rzzpeU6Wu26 agBg9lP0Fe+PIMTW7jn1ghFilzAVJrGmPAT8FKm8x1c5RHHwhJJVN0C4bnTxizIh+9Pm o4o8keYeA1lwHT0CkXoPNLGZshYpjyWOipcvVWCW7BqCN4vwpSEM5R8ezLMC0GUlaoP8 9vxw== X-Gm-Message-State: AOAM533rCTrdxu0jZDXfkAL+XE4h6F7JJUVyYSRLqWwQtYX+3+Tkh953 rGMQ93NixtwafSy4z4lM1jlSgQ== X-Google-Smtp-Source: ABdhPJyd3K/vOjSQRpmW/BPtI4ULWJHzI4gHHAVSiple1p4cMImpKslL1wmPuTtEHIBLMls8/g+iNQ== X-Received: by 2002:a17:902:f151:b0:158:a253:b4e6 with SMTP id d17-20020a170902f15100b00158a253b4e6mr5526637plb.32.1649907831760; Wed, 13 Apr 2022 20:43:51 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:93b2:d39f:36ee:5bcf]) by smtp.gmail.com with ESMTPSA id 21-20020a630115000000b00382a0895661sm523721pgb.11.2022.04.13.20.43.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 20:43:51 -0700 (PDT) Date: Wed, 13 Apr 2022 20:43:47 -0700 From: Fangrui Song To: "H.J. Lu" Cc: Alan Modra , GNU C Library , Tulio Magno Quites Machado Filho Subject: Re: DT_RELR without libc.so dependency Message-ID: <20220414034347.n5jege3qkumzepm4@google.com> References: <20220228064052.3413334-1-amodra@gmail.com> <20220409001412.ezhmy7i2sqq7t256@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-19.9 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 14 Apr 2022 03:43:54 -0000 On 2022-04-13, H.J. Lu wrote: >On Wed, Apr 13, 2022 at 5:34 PM Alan Modra wrote: >> >> On Fri, Apr 08, 2022 at 05:14:12PM -0700, Fangrui Song wrote: >> > HJ's DT_RELR patch series has been upgraded to v7 >> > (https://patchwork.sourceware.org/project/glibc/list/?series=8295) >> > >> > git-pw series apply 8295 >> > # `Add --disable-default-dt-relr` does not apply cleanly >> > >> > If no regressions with default DT_RELR, that will be cool! >> >> I did find one error when testing a build of glibc using Ubuntu gcc-8. >> elf/filter fails with "error while loading shared libraries: >> .../elf/filtmod1.so: DT_RELR without GLIBC_ABI_DT_RELR dependency". >> >> A little analysis shows the problem occurs when filtmod1.so is linked >> with --as-needed and libc.so is not needed. filtmod1.so ends up with >> no .gnu.version or .gnu.version_r sections, and of course no >> GLIBC_ABI_DT_RELR version. >> >> The error check is not one that belongs in ld.so. If you have the >> error checking code, then you have DT_RELR support in ld.so and there >> is no reason at all to refuse to run the program! The check should be >> in the linker, if anywhere. >> > >The GLIBC_ABI_DT_RELR dependency is added to avoid the random >crush at run-time with older glibc binaries. Since it is possible to create >a DSO with DT_RELR, but without the libc.so dependency. Should ld.so >skip the GLIBC_ABI_DT_RELR check if the DSO doesn't depend on >libc.so? Looks good.