From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id ED6143858C2D for ; Wed, 30 Mar 2022 17:17:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ED6143858C2D Received: by mail-oi1-x22a.google.com with SMTP id i7so8584113oie.7 for ; Wed, 30 Mar 2022 10:17:29 -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=k/eY59mKFDIX0aZnEyo+u0ZvuTekTh0Gg334fLQUcAw=; b=fpJEbLOpyaV+nNVf4woiLBhlJpAGP90Zl0tdDvfZzqZLsEKpAJ7+kakwVwtshQZ5fF F/KsRkHYLGhjRqvWBLgywqVrYcRPn43NNRBMqO2vpV3CqiOrY8KWr7eUVm/iRyUCOD8y ORez4QjXuFPG4jTdiewA2sYzUFTFLPcfpZVAVJZjxzxUCfkJV42ztcW9h69RJ+fNDLz1 yjoQC9x34VCLH921HUg7gHMjXEQzr5qTITx3J9T4KO+Gpl6HlE2rzNYtNN28oRqORLhE Zta/bfHRAq3+GNELZjcIo2pyMUeScZWUfqDDLt2AXbYoVaQRSftYbJTot4Vf859mKXmA 1dkg== X-Gm-Message-State: AOAM531tQLUlwgX+2EnJN9w8tGd/+X1zS0VpM2f2qBywiQBtc8jsq6eG Ihpz3xrXOX0fKVkRof2mDbpt+PG70n7zvQ== X-Google-Smtp-Source: ABdhPJyBUIozoa6coWHFWu1R3Q2P6iT2H5OChw3YOc9U4Zo1gHjvI7j/X774gbv+xoKT8vOvZoL+HA== X-Received: by 2002:aca:f07:0:b0:2ec:9f1a:e61a with SMTP id 7-20020aca0f07000000b002ec9f1ae61amr394122oip.11.1648660649176; Wed, 30 Mar 2022 10:17:29 -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 bx16-20020a0568081b1000b002f7966564b4sm1738932oib.43.2022.03.30.10.17.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 30 Mar 2022 10:17:28 -0700 (PDT) Message-ID: <5f32b52c-508b-dcba-af9b-7ff248cc3c1d@linaro.org> Date: Wed, 30 Mar 2022 14:17:25 -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> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 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:17:32 -0000 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.