From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id 3F5A73858D35 for ; Fri, 4 Feb 2022 21:09:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3F5A73858D35 Received: by mail-pf1-x436.google.com with SMTP id 192so6128929pfz.3 for ; Fri, 04 Feb 2022 13:09:18 -0800 (PST) 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=7qSWGuXX0Zj/EFEkaYQwG9DX659Q1s8O0zrL+9+Bkx8=; b=ZTkF7SvmhECNYL5q0QDZKL/SLb5m6C9xn93WdZspoI/5Yhqpn7fR9YWQYNEFFxHcY4 G8yrlomOpDpzCqQT+XbxWQ8aCeY2LQSCaAHlN9YXcH2gEH54M11II/ZVJIn5HCVv7mu5 Wbquhd6aBWHqaAmRWoYwkjdbxw3r3RTXna/ZnEp6B9eDgigM19k+Xmlofvaj2LyUHaRD 1CnCHJzFY2cI8AvYhdpbHtM7SFEc/EqT5TVXdT9C7Imae6hETHqoRAyTCvko+JPv49uD kp5jY4nZr6jwtg4yyIV8pLAeSTIU1mL7pa+9Xp07qVH+lvKcLQyFtSTp/bRe211GiUIZ eLYA== X-Gm-Message-State: AOAM532QIipVLGbzjbL9PCoXYF5Nt+qhmJsEw/z6W2NB/hM21lfxNirB YPB99d9nL/A9CPeaXj8wOe9rMXVf3wLcC1qpe+PzzQ+LaJM= X-Google-Smtp-Source: ABdhPJyef039qy0rZMKg4Lok1GNfc6MN6a4VkndT6HdUp3/go+DHXgS3Lp/VxxeSoM8tnw8TsFD72ntqlzlQnPcsVLY= X-Received: by 2002:a63:3e8b:: with SMTP id l133mr712709pga.210.1644008957245; Fri, 04 Feb 2022 13:09:17 -0800 (PST) MIME-Version: 1.0 References: <20220203180948.2744-1-hjl.tools@gmail.com> <20220203180948.2744-4-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Fri, 4 Feb 2022 13:08:41 -0800 Message-ID: Subject: Re: [PATCH 3/7] Add GLIBC_ABI_DT_RELR for DT_RELR support To: Joseph Myers Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3021.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2022 21:09:19 -0000 On Fri, Feb 4, 2022 at 1:01 PM Joseph Myers wrote: > > On Fri, 4 Feb 2022, H.J. Lu via Libc-alpha wrote: > > > Good point. How about "enable DT_RELR only if SUPPORT_DT_RELR is > > defined? Currently, only x86 defines SUPPORT_DT_RELR. > > My preference would be: > > 1. Support user executables and shared libraries with RELR relocations > across all platforms, unconditionally. RELR is kind of like static PIE. Not all architectures support it. RELR should be enabled only if there is a linker which supports -z pack-relative-relocs. That is the main reason why RELR is enabled in glibc 2.35. > 2. Build glibc to use RELR relocations in its own executables and shared > libraries based on an architecture-independent configure test for whether > linker support is present. This is implemented in commit 486531c29b0fa48287b29ea20e805bee1ec19a67 Author: H.J. Lu Date: Sat Jan 22 05:44:45 2022 -0800 Add --disable-default-dt-relr which is similar to --disable-default-pie. > And avoid any architecture-specific conditional relating to RELR support > in glibc completely. > > *If* it turns out to be hard to have a fully reliable > architecture-independent configure test for linker support, and the > architecture-independent test reports linker support to be present (in an > actual binutils release, not just the development mainline) for an > architecture where that support is in fact buggy and incomplete, then we > might consider adding an architecture-specific test on that architecture > to disable building glibc to use RELR relocations with the buggy linker > version. That is, architecture-specific tests would only be to disable > building glibc to use RELR relocations, not to enable it, and only when > the bugs in linker support on that architecture can't readily be detected > by an architecture-independent test. The default for all existing and > future architectures would be to follow the results of the > architecture-independent configure test. -- H.J.