Message ID | 20220228064052.3413334-1-amodra@gmail.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BCADA3858C20 for <patchwork@sourceware.org>; Mon, 28 Feb 2022 06:42:00 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCADA3858C20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1646030520; bh=lxLsZwZZi7hBLg1oRxgNnnEkDO3aW1ySEaYJ4SM8nIU=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=TdEy8ZS6nxT+3RPm87nw0SfsNSOzPyLnZ4uToB04pvVrPySFDZ25+89tQHA8IixA2 bFmwE8ut07+DmKonZL3uE4kaWWT2UKib8azgzHa1Gw2AhR3dpK0j16pW6qh2NIq1rs MrERW6HnzLE1uMZWtRzne16COtkOj2W+gnO7Fw4o= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id E64EE3858C83 for <libc-alpha@sourceware.org>; Mon, 28 Feb 2022 06:41:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E64EE3858C83 Received: by mail-pj1-x1036.google.com with SMTP id m22so10301939pja.0 for <libc-alpha@sourceware.org>; Sun, 27 Feb 2022 22:41:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lxLsZwZZi7hBLg1oRxgNnnEkDO3aW1ySEaYJ4SM8nIU=; b=jf9BGS0bf3UzjKUi3XtTTqaeNv+lA2sqA90Teqy3MPHfCUckMzUDPX8CfsEEqkw9sr OfQ4WQB19J9AD+Ly4RYPyJkEYgsknxbtngrZPD3XS50VGYQOsv9FJCAwWXnx1aJaVR8B 3NhQkkejyJ/s1UUrLFFJCcVQX78lXZcvLVy5o9+UEnSJhIw3nXZrNTPaEyPd3r0pLfDM qErCqLeAo/dlBV2fq7zN6AbkjufmSUqYXRPsYH+8m0T3x8QiS+Yvg+l8FOgxcbh8qAlo RtlpaZtCyDCfLn3nARxM6uFxe3CN16oUGesW8AeOL8szSoOFT0t1L3Sdrg91andTwM+T MMNw== X-Gm-Message-State: AOAM531Ta+loFLdKJBo/i7GAoOT/Bo9oRyh1m5xWrcw4hMdxGvlsx3Ct zCbkY/R87ZqX22EIOmbEhDs8MFo2Zk0= X-Google-Smtp-Source: ABdhPJxhRK3TiLmwNWO05s3GsRwAzQvw5R3DefX0Sg8bpJ/5pWRpe4+ws1cjOEPdwG885KgIiKkSYA== X-Received: by 2002:a17:902:d4c6:b0:150:15ed:3cd9 with SMTP id o6-20020a170902d4c600b0015015ed3cd9mr18498445plg.2.1646030495677; Sun, 27 Feb 2022 22:41:35 -0800 (PST) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:f31d:e338:6c7b:8cfa]) by smtp.gmail.com with ESMTPSA id q15-20020a63504f000000b0037425262293sm9130249pgl.43.2022.02.27.22.41.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 27 Feb 2022 22:41:34 -0800 (PST) To: libc-alpha@sourceware.org Subject: [PATCH v2 0/4] PowerPC64 static-pie Date: Mon, 28 Feb 2022 17:10:48 +1030 Message-Id: <20220228064052.3413334-1-amodra@gmail.com> X-Mailer: git-send-email 2.30.2 In-Reply-To: <Ye1NJQwEpe7AyNYD@squeak.grove.modra.org> References: <Ye1NJQwEpe7AyNYD@squeak.grove.modra.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3029.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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 <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> From: Alan Modra via Libc-alpha <libc-alpha@sourceware.org> Reply-To: Alan Modra <amodra@gmail.com> Cc: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>, Alan Modra <amodra@gmail.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series | PowerPC64 static-pie | |
Message
Alan Modra
Feb. 28, 2022, 6:40 a.m. UTC
This is a repost of the series at https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html incorporating review comments. Changes are: - subject lines changed to comply with glibc commit log standards - patch 1/4 log now mentions making a couple of symbols hidden - patch 2/4 makes at_platform available to early ifunc resolvers as well as hwcap. - patch 3/4 log mentions stinfo->init and stinfo->fini being unused - patch 4/4 PI_STATIC_AND_HIDDEN comment explains what is going on patch 2/4 is the only code change from the previous series. Testsuite results now show no regressions on powerpc64le-linux. I haven't reposted the old patch 4/5 as it was just a side-issue I noticed when looking over relative relocations. https://sourceware.org/pipermail/libc-alpha/2022-January/135603.html I think it qualifies as an obvious patch so will commit it separately from this series. Alan Modra (4): powerpc64: Use medium model toc accesses throughout powerpc64: Set up thread register for _dl_relocate_static_pie powerpc: Relocate stinfo->main powerpc64: Enable static-pie sysdeps/powerpc/hwcapinfo.c | 8 ++--- sysdeps/powerpc/hwcapinfo.h | 3 +- sysdeps/powerpc/nptl/tls.h | 8 ++--- sysdeps/powerpc/powerpc64/__longjmp-common.S | 8 +++-- sysdeps/powerpc/powerpc64/configure | 6 ++++ sysdeps/powerpc/powerpc64/configure.ac | 9 ++++++ sysdeps/powerpc/powerpc64/dl-machine.h | 33 +++++++++++++++++--- sysdeps/powerpc/powerpc64/dl-trampoline.S | 8 +++-- sysdeps/powerpc/powerpc64/setjmp-common.S | 8 +++-- sysdeps/powerpc/powerpc64/start.S | 3 +- sysdeps/powerpc/powerpc64/sysdep.h | 6 ++-- sysdeps/unix/sysv/linux/powerpc/Makefile | 6 ++++ sysdeps/unix/sysv/linux/powerpc/libc-start.c | 15 +++++++-- 13 files changed, 93 insertions(+), 28 deletions(-)
Comments
On Mon, Feb 28, 2022 at 05:10:48PM +1030, Alan Modra wrote: > This is a repost of the series at > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html > incorporating review comments. I neglected to say that this series was tested powerpc64le-linux showing no regressions. I also tested powerpc64-linux today, both static-pie and dt_relr no regressions. (Well, there were 3 tests that regressed, but passed when run by hand. Probably some sort of resource starvation.)
On Fri, Mar 04, 2022 at 11:18:10PM +1030, Alan Modra wrote: > On Mon, Feb 28, 2022 at 05:10:48PM +1030, Alan Modra wrote: > > This is a repost of the series at > > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html > > incorporating review comments. > > I neglected to say that this series was tested powerpc64le-linux > showing no regressions. I also tested powerpc64-linux today, both > static-pie and dt_relr no regressions. (Well, there were 3 tests that > regressed, but passed when run by hand. Probably some sort of > resource starvation.) Ping. https://sourceware.org/pipermail/libc-alpha/2022-February/136727.html
Alan Modra via Libc-alpha <libc-alpha@sourceware.org> writes: > This is a repost of the series at > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html > incorporating review comments. > > Changes are: > - subject lines changed to comply with glibc commit log standards > - patch 1/4 log now mentions making a couple of symbols hidden > - patch 2/4 makes at_platform available to early ifunc resolvers > as well as hwcap. > - patch 3/4 log mentions stinfo->init and stinfo->fini being unused > - patch 4/4 PI_STATIC_AND_HIDDEN comment explains what is going on > > patch 2/4 is the only code change from the previous series. Testsuite > results now show no regressions on powerpc64le-linux. I'm still seeing the following failures on powerpc64le-linux: FAIL: elf/tst-tls1-static-non-pie FAIL: gmon/tst-gmon-static FAIL: gmon/tst-gmon-static-gprof Am I missing anything? I used different GCC and Binutils versions ranging between: - GCC v8 and v11 - Binutils 2.30 and 2.38 (2020-03-04) Anyway, this is a summary of what I think about these patches: - Patch 1: Looks good to me. - Patch 2: Looks good to me. - Patch 3: Looks good to me after a minor change. - Patch 4: Hopefully I'm just missing a detail. Otherwise, I believe we should delay it until the previous issues are fixed. Let me elaborate this replying to each patch.
On 2022-04-08, Alan Modra via Libc-alpha wrote: >On Fri, Mar 04, 2022 at 11:18:10PM +1030, Alan Modra wrote: >> On Mon, Feb 28, 2022 at 05:10:48PM +1030, Alan Modra wrote: >> > This is a repost of the series at >> > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html >> > incorporating review comments. >> >> I neglected to say that this series was tested powerpc64le-linux >> showing no regressions. I also tested powerpc64-linux today, both >> static-pie and dt_relr no regressions. (Well, there were 3 tests that >> regressed, but passed when run by hand. Probably some sort of >> resource starvation.) > >Ping. > >https://sourceware.org/pipermail/libc-alpha/2022-February/136727.html 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!
On Fri, Apr 08, 2022 at 07:27:32PM -0300, Tulio Magno Quites Machado Filho wrote: > Alan Modra via Libc-alpha <libc-alpha@sourceware.org> writes: > > > This is a repost of the series at > > https://sourceware.org/pipermail/libc-alpha/2022-January/135598.html > > incorporating review comments. > > > > Changes are: > > - subject lines changed to comply with glibc commit log standards > > - patch 1/4 log now mentions making a couple of symbols hidden > > - patch 2/4 makes at_platform available to early ifunc resolvers > > as well as hwcap. > > - patch 3/4 log mentions stinfo->init and stinfo->fini being unused > > - patch 4/4 PI_STATIC_AND_HIDDEN comment explains what is going on > > > > patch 2/4 is the only code change from the previous series. Testsuite > > results now show no regressions on powerpc64le-linux. > > I'm still seeing the following failures on powerpc64le-linux: > > FAIL: elf/tst-tls1-static-non-pie > FAIL: gmon/tst-gmon-static > FAIL: gmon/tst-gmon-static-gprof > > Am I missing anything? > > I used different GCC and Binutils versions ranging between: > - GCC v8 and v11 > - Binutils 2.30 and 2.38 (2020-03-04) I was testing with mainline binutils and gcc (gcc-12 20220122). It is quite likeley that bleeding edge tools are required for static-pie on ppc64le. I'll see if I can recreate some of your results, in particular with 2.38 binutils. Mainline ppc64 binutils has a patch that changes linker behaviour for absolute symbols. I haven't backported that patch, or the DT_RELR support, to the 2.38 branch because those changes might result in breakage. I'd rather let them mature a while on mainline. Here are the results I was seeing with both static-pie and relr support enabled for ppc64 vs. basline glibc. Same toolchain for both glibc builds. --- base_results 2022-03-04 04:36:09.71152949 -0600 +++ staticpierelr_results 2022-03-04 04:36:17.263676034 -0600 @@ -24,7 +24,7 @@ UNSUPPORTED: time/tst-settimeofday Summary of test results: 3 FAIL - 4798 PASS + 4802 PASS 19 UNSUPPORTED 16 XFAIL 2 XPASS The three fails common to both test runs were FAIL: math/test-ibm128-llround FAIL: math/test-ibm128-y1 FAIL: nptl/tst-pthread-gdb-attach-static The extra PASSes are new DT_RELR tests I think. > Anyway, this is a summary of what I think about these patches: > > - Patch 1: Looks good to me. > - Patch 2: Looks good to me. > - Patch 3: Looks good to me after a minor change. > - Patch 4: Hopefully I'm just missing a detail. Otherwise, I believe we should > delay it until the previous issues are fixed. Thanks, I'm happy to leave out patch 4 for the time being, and perhaps change it so that --enable-static-pie on the configure line is needed for ppc64. First three pushed along with the dl_vdso_vsym tweak, but I did see this weird warning, whatever that means.. alan@squeak:~/src/glibc-current$ git push origin 1a85970f41ea1e5abe6da2298a5e8fedcea26b70:master Enumerating objects: 62, done. Counting objects: 100% (62/62), done. Delta compression using up to 32 threads Compressing objects: 100% (37/37), done. Writing objects: 100% (39/39), 6.06 KiB | 6.06 MiB/s, done. Total 39 (delta 33), reused 0 (delta 0), pack-reused 0 remote: Traceback (most recent call last): remote: File "/usr/local/bin/irkerhook.py", line 545, in <module> remote: ship(extractor, commit, not notify) remote: File "/usr/local/bin/irkerhook.py", line 467, in ship remote: privmsg = unicode(metadata) remote: File "/usr/local/bin/irkerhook.py", line 99, in __unicode__ remote: if e.code == 401: remote: AttributeError: 'URLError' object has no attribute 'code' remote: *** !!! WARNING: /git/glibc.git/hooks-bin/post-receive returned code: 1. To ssh://sourceware.org/git/glibc.git c0efbf8920..1a85970f41 1a85970f41ea1e5abe6da2298a5e8fedcea26b70 -> master
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.
On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> 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?
On 2022-04-13, H.J. Lu wrote: >On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> 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.
On Wed, Apr 13, 2022 at 06:54:17PM -0700, H.J. Lu wrote: > On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> 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? I understand why you want a dependency, but I do not see a hard requirement for l_abi_version or any code using it. If you try to run a new binary with DT_RELR using an old glibc or even current glibc without relr support, you'll get "version `GLIBC_ABI_DT_RELR' not found". That is sufficient, presuming there is a GLIBC_ABI_DT_RELR version in the binary. If there *isn't* a GLIBC_ABI_DT_RELR version then running that binary on an older glibc probably will crash. Putting a check in a newer ld.so doesn't help much with that, except show up this case where the dependency isn't there. I guess the check is justifiable under some DL_DEBUG flag. Lack of a dependency is either a linker bug or a relr design bug. Nitpick: isn't the actual dependency on ld.so rather than libc.so?
On Wed, Apr 13, 2022 at 10:19 PM Alan Modra <amodra@gmail.com> wrote: > > On Wed, Apr 13, 2022 at 06:54:17PM -0700, H.J. Lu wrote: > > On Wed, Apr 13, 2022 at 5:34 PM Alan Modra <amodra@gmail.com> 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? > > I understand why you want a dependency, but I do not see a hard > requirement for l_abi_version or any code using it. If you try to run > a new binary with DT_RELR using an old glibc or even current glibc > without relr support, you'll get "version `GLIBC_ABI_DT_RELR' not > found". That is sufficient, presuming there is a GLIBC_ABI_DT_RELR > version in the binary. If there *isn't* a GLIBC_ABI_DT_RELR version > then running that binary on an older glibc probably will crash. > Putting a check in a newer ld.so doesn't help much with that, except > show up this case where the dependency isn't there. I guess the check > is justifiable under some DL_DEBUG flag. > > Lack of a dependency is either a linker bug or a relr design bug. > Nitpick: isn't the actual dependency on ld.so rather than libc.so? > The goal is to require a glibc with GLIBC_ABI_DT_RELR when DT_RELR is used. Since a shared library usually isn't linked with ld.so, libc.so is checked. I am working on v9 to support: 1. A DT_RELR shared library without DT_NEEDED. 2. A DT_RELR shared library without DT_VERNEED. 3. A DT_RELR shared library without libc.so on DT_NEEDED.