From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 10F5E385801B for ; Wed, 30 Mar 2022 17:39:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 10F5E385801B Received: by mail-ot1-x332.google.com with SMTP id n19-20020a9d7113000000b005cd9cff76c3so15392586otj.1 for ; Wed, 30 Mar 2022 10:39:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=XtrQGtZyMstts2N25vEiHFiF7wNm8+2g3duHdvoGgNU=; b=T4bntKQZexwix2CeM1wZzh6V74kKyP33OYFeG3Mdr7vnStIx5f/M34R4xns17+b25L cHH9ufhVMpwe1vQ/x9NIxSza5USO6AYXO/XHgeKqCCG7Av+10fyXu7BK0eL4WgI8QrwN Owk7AMpz5SVIXH/b7qNNFs86/u/HY7GScQKnEaM3Yqgytz1Mo6Odf0x+3awM1aMIRAEK TmPxnNas0qEQCwmLnqIMGL5hV9JfZb8zKDXnJ753tSrRxxAGuoOvKk/ejfG7xbqyISmK 6ZDJqadJL25zhKsTVcZoVJ5PJ5gLFt8eJGWiuc3nbWquW6md7/QznITmn3Lcy4kUr/Sm r/iA== X-Gm-Message-State: AOAM533FPsXW9VFn31mjPruJnm2ucvIA9bpiehZNNMuOHuJzkOZ6FoII gZ2aYwwAj1Wp6/LjMCnr9ntXKvNYTomj4Q== X-Google-Smtp-Source: ABdhPJwnsYXizmJkNfyxx53IJu1aAbOwjezvk1hsOAuSJEfvvrpfEKuwCwoobJdp770oNk9qoqkbEQ== X-Received: by 2002:a05:6830:2242:b0:5cd:9d05:b249 with SMTP id t2-20020a056830224200b005cd9d05b249mr3746858otd.203.1648661989305; Wed, 30 Mar 2022 10:39:49 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:a6c0:ca7b:5b69:d952:46d0? ([2804:431:c7cb:a6c0:ca7b:5b69:d952:46d0]) by smtp.gmail.com with ESMTPSA id d12-20020a056871040c00b000d9eed0f8fdsm10023324oag.14.2022.03.30.10.39.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Mar 2022 10:39:48 -0700 (PDT) Message-ID: <5151cd92-2401-cdb3-ca6d-542630ade06e@linaro.org> Date: Wed, 30 Mar 2022 14:39:46 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH v6 3/5] Add GLIBC_ABI_DT_RELR for DT_RELR support Content-Language: en-US To: "H.J. Lu" Cc: GNU C Library , Joseph Myers References: <20220310200329.1935466-1-hjl.tools@gmail.com> <20220310200329.1935466-4-hjl.tools@gmail.com> <066eedff-b1d4-ec3c-3716-5846e2646f9a@linaro.org> <5f32b52c-508b-dcba-af9b-7ff248cc3c1d@linaro.org> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2022 17:39:53 -0000 On 30/03/2022 14:32, H.J. Lu wrote: > Does the linker add the version dependency? Does ld.so support DT_RELR? > $ readelf -V test | grep GLIBC_ABI_DT_RELR 0x0030: Name: GLIBC_ABI_DT_RELR Flags: none Version: 4 But ld.so does not support DT_RELR $ grep libc_cv_dt_relr config.log libc_cv_dt_relr=no > On Wed, Mar 30, 2022, 10:17 AM Adhemerval Zanella > wrote: > > > > On 30/03/2022 11:41, H.J. Lu wrote: > > On Wed, Mar 30, 2022 at 7:18 AM Adhemerval Zanella > > > wrote: > >> > >> > >> > >> On 29/03/2022 19:29, H.J. Lu wrote: > >>> On Tue, Mar 29, 2022 at 9:52 AM Adhemerval Zanella > >>> > wrote: > >>>> > >>>> > >>>> > >>>> On 10/03/2022 17:03, H.J. Lu via Libc-alpha wrote: > >>>>> The EI_ABIVERSION field of the ELF header in executables and shared > >>>>> libraries can be bumped to indicate the minimum ABI requirement on the > >>>>> dynamic linker.  However, EI_ABIVERSION in executables isn't checked by > >>>>> the Linux kernel ELF loader nor the existing dynamic linker.  Executables > >>>>> will crash mysteriously if the dynamic linker doesn't support the ABI > >>>>> features required by the EI_ABIVERSION field.  The dynamic linker should > >>>>> be changed to check EI_ABIVERSION in executables. > >>>>> > >>>>> Add a glibc version, GLIBC_ABI_DT_RELR, to indicate DT_RELR support so > >>>>> that the existing dynamic linkers will issue an error on executables with > >>>>> GLIBC_ABI_DT_RELR dependency.  Issue an error if there is a DT_RELR entry > >>>>> without GLIBC_ABI_DT_RELR dependency nor GLIBC_PRIVATE definition. > >>>>> > >>>>> Support __placeholder_only_for_empty_version_map as the placeholder symbol > >>>>> used only for empty version map to generate GLIBC_ABI_DT_RELR without any > >>>>> symbols. > >>>> > >>>> I think it only make sense to add the GLIBC_ABI_DT_RELR if the ABI actually > >>>> supports DT_RELR, otherwise if the ABI start to support old glibcs might > >>>> wrongly assumes DT_RELR and fails with undefined behavior at runtime > >>>> (which this patch essentially tries to avoid). > >>> > >>> The DT_RELR set enables DT_RELR in glibc for all targets. > >> If I understood correctly, if we add GLIBC_ABI_DT_RELR on 2.36 but only enable > >> it on some architecture on 2.37 and try to run a binary with DT_RELR enabled > >> on glibc 2.36, _dl_check_map_versions won't accuse a failure and it will > >> eventually only fail at runtime (since relocation won't be applied).  My > >> understanding we are trying to avoid such failures. > > > > My patch set enables DT_RELR and GLIBC_ABI_DT_RELR on glibc 2.36 > > for all, regardless of binutils version.   There is no per-arch > > behavior.    Only > > DT_RELR run-time tests are enabled for linkers with -z pack-relative-relocs. > > But it still does not fail when the architecture does not actually implement > RELR even when static linker does: > > $ clang --target=aarch64-linux-gnu -fuse-ld=lld -Wl,-z,pack-relative-relocs -fpie -o test -pie test.c > $ aarch64-glibc-linux-gnu-readelf -S test | grep relr\.dyn >   [ 9] .relr.dyn         RELR             0000000000000528  00000528 > $ ./elf/ld.so --library-path . ./test > $ > > I would expect that even when binary adds GLIBC_ABI_DT_RELR, if dynamic linker > does not have DT_RELR it would fail early. >