From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id 2AF283858C53 for ; Thu, 14 Apr 2022 17:56:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2AF283858C53 Received: by mail-pj1-x102c.google.com with SMTP id mm4-20020a17090b358400b001cb93d8b137so9953876pjb.2 for ; Thu, 14 Apr 2022 10:56:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6YM1weA47/tzGwR8OoGpyUGC8bUu7WB/3YDaQlUO5PY=; b=BSO8JRDZw3RDJrZx6jWid44vL3wz7OwS8SGUpQ3pkFkP4xBEjg231spAF7CbFehpzr 6EcXToj/rXYpyZTFeEtTTtfVl5pV0pVXvc0BKwsm0Z95E1RhD3KN/nd0TpNDP8mvev+m C1lZs/lxDvG9b47oAh3D/gM1Vc/sexUax4uumU/h3u5EKPJ7wP3ORO0KB5AJAeOt7PzC jvi/dnXAM+MG1MM6UVcJc5gttJYX37cYovi2JYkoiw8dfuduwqnLMEMRnmSnU2eUaDX6 q5KoKhb6dxhk7VDCpFdgikfrjYjRLBzSo4m77h50ucjl/WDxQx9K5dkjEJECyN4JR6QK Qv0A== X-Gm-Message-State: AOAM53360G8lIWclzXhRhR/5LwamV5R6nnrH/0qceEM+uijTPEKXc3Ib 3E+DT84dz/EzJtii974xeAjeerws9W8hGMKGfiBkxleT0x4= X-Google-Smtp-Source: ABdhPJw4ff2KQdxmJgaKVnk78ToUkkspF93LKbeXw+3H4Flf7Mkhh1RvVW/wrPTYoTScC2TliTiv/Buj1izvKtus7TM= X-Received: by 2002:a17:90a:ba15:b0:1cb:be7d:bbca with SMTP id s21-20020a17090aba1500b001cbbe7dbbcamr5475865pjr.143.1649958996132; Thu, 14 Apr 2022 10:56:36 -0700 (PDT) MIME-Version: 1.0 References: <20220228064052.3413334-1-amodra@gmail.com> <20220409001412.ezhmy7i2sqq7t256@google.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 14 Apr 2022 10:55:59 -0700 Message-ID: Subject: Re: DT_RELR without libc.so dependency To: Alan Modra Cc: Fangrui Song , GNU C Library , Tulio Magno Quites Machado Filho Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.9 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, URIBL_BLACK 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 17:56:39 -0000 On Wed, Apr 13, 2022 at 10:19 PM Alan Modra 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 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. -- H.J.