Message ID | 20220203180948.2744-1-hjl.tools@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 95A1C3858404 for <patchwork@sourceware.org>; Thu, 3 Feb 2022 18:11:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 95A1C3858404 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1643911901; bh=e4JR23qL6yCZGZutZKHkYJD8JX9wc1vcZtfKQkUUR78=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=VhWhfVKphiuPGFcp9KivStUgMul0RMuXVjL4e64pUyWklxhtY1U25WK3KakEnRrAR y63ntvHSIl+EvkyNXe67ApBZhKHduViyss2ughE5eMNY/Re7bFEynzT5TM2ALkS7EL B/zxTHBrA45Y+3RJfuZPS/MbfNpbf7pLWEDDZcag= X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 68AF23858C60 for <libc-alpha@sourceware.org>; Thu, 3 Feb 2022 18:09:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68AF23858C60 Received: by mail-pl1-x631.google.com with SMTP id x11so2833926plg.6 for <libc-alpha@sourceware.org>; Thu, 03 Feb 2022 10:09:52 -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:mime-version :content-transfer-encoding; bh=e4JR23qL6yCZGZutZKHkYJD8JX9wc1vcZtfKQkUUR78=; b=ALHFT0yTNQ6lO8ujMlrVon8e1KUgyJJWWjB4hrtaoJXhekVJF0EafC9+Hi0AkAFTb6 R/2xmpO56nX9/6mlwn/8Y8j9pZwmlyZwemko8gPR42CyOt1i8HCZ/Y37Z5wVYk3SV8jS swWe1ohjy4PuQ/kQm6EoR4Lyvg51ihWPBBogAmvwt2AZcel3COCoN7R+yNTYodAjEIeX oeYCIUNEGQTU339LyYwxO5L1i2e9OUbRny1QQ6tGrlbmNPQhfGXDwPcoar6c7w2q+MAg 9//oIORsOXh2ep/kE0cg3IKpPJX5e8Kb2EyS8SD1+Ap6CONUVwSC/fvOTkiW7QBKGIMc AHpA== X-Gm-Message-State: AOAM533eie9kKpJFgg2EOE6W+ztDPXtRTqc/mAX3cnlXeQJ2zKREW+V4 aLZrSazFKGlr3VBM13uKz7y5uBpwZDE= X-Google-Smtp-Source: ABdhPJyVT0bTwFTsc1vBaLN2HEtU3xYpOJW4uTGZVrjRHTkKb7iEG4G2PsK6ZelRxsZXxbdzOiscnA== X-Received: by 2002:a17:903:182:: with SMTP id z2mr37342538plg.67.1643911791474; Thu, 03 Feb 2022 10:09:51 -0800 (PST) Received: from gnu-tgl-2.localdomain ([172.58.38.240]) by smtp.gmail.com with ESMTPSA id b4sm10843192pfv.188.2022.02.03.10.09.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 10:09:50 -0800 (PST) Received: from gnu-tgl-2.. (localhost [IPv6:::1]) by gnu-tgl-2.localdomain (Postfix) with ESMTP id C20BB3004A4; Thu, 3 Feb 2022 10:09:48 -0800 (PST) To: libc-alpha@sourceware.org Subject: [PATCH 0/7] Support DT_RELR relative relocation format Date: Thu, 3 Feb 2022 10:09:41 -0800 Message-Id: <20220203180948.2744-1-hjl.tools@gmail.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3023.2 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 <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: "H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org> Reply-To: "H.J. Lu" <hjl.tools@gmail.com> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
Support DT_RELR relative relocation format
|
|
Message
H.J. Lu
Feb. 3, 2022, 6:09 p.m. UTC
PIE and shared objects usually have many relative relocations. In 2017/2018, SHT_RELR/DT_RELR was proposed on https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/GxjM0L-PBAAJ ("Proposal for a new section type SHT_RELR") and is a pre-standard. RELR usually takes 3% or smaller space than R_*_RELATIVE relocations. The virtual memory size of a mostly statically linked PIE is typically 5~10% smaller. Binutils 2.38 supports DT_RELR on x86 with the -z report-relative-reloc option. When DT_RELR is enabled, ld adds a GLIBC_ABI_DT_RELR symbol version dependency on libc.so to outputs. The DT_RELR support is enabled in ld.so only if the linker supports -z report-relative-reloc option. DT_RELR is enabled in glibc shared libraries and position independent executables (PIE) automatically if linker supports -z pack-relative-relocs nd the architecture defines SUPPORT_DT_RELR in config.h. At the moment, only x86 targets define SUPPORT_DT_RELR. The DT_RELR usage in glibc can be disabled with --disable-default-dt-relr. Tested with binutils 2.38 on i686, x86-64 and x32. Fangrui Song (1): elf: Support DT_RELR relative relocation format [BZ #27924] H.J. Lu (6): elf: Properly handle zero DT_RELA/DT_REL values Add GLIBC_ABI_DT_RELR for DT_RELR support x86/configure.ac: Define PI_STATIC_AND_HIDDEN/SUPPORT_STATIC_PIE x86: Define SUPPORT_DT_RELR Add --disable-default-dt-relr NEWS: Mention DT_RELR support INSTALL | 6 +++ Makeconfig | 19 +++++++++ Makerules | 2 + NEWS | 5 +++ config.h.in | 6 +++ configure | 84 +++++++++++++++++++++++++++++++++++++ configure.ac | 34 +++++++++++++++ elf/Makefile | 36 ++++++++++++++-- elf/Versions | 7 ++++ elf/dynamic-link.h | 40 +++++++++++++++++- elf/elf.h | 13 +++++- elf/get-dynamic-info.h | 19 +++++++-- elf/libc-abi-version.exp | 1 + elf/tst-relr-pie.c | 1 + elf/tst-relr.c | 64 ++++++++++++++++++++++++++++ manual/install.texi | 5 +++ scripts/abilist.awk | 2 + scripts/versions.awk | 7 +++- sysdeps/i386/configure | 6 --- sysdeps/i386/configure.ac | 7 ---- sysdeps/x86/configure | 9 ++++ sysdeps/x86/configure.ac | 10 +++++ sysdeps/x86_64/configure | 6 --- sysdeps/x86_64/configure.ac | 7 ---- 24 files changed, 360 insertions(+), 36 deletions(-) create mode 100644 elf/libc-abi-version.exp create mode 100644 elf/tst-relr-pie.c create mode 100644 elf/tst-relr.c
Comments
On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote: > DT_RELR is enabled in glibc shared libraries and position independent > executables (PIE) automatically if linker supports -z pack-relative-relocs > nd the architecture defines SUPPORT_DT_RELR in config.h. At the moment, > only x86 targets define SUPPORT_DT_RELR. The patch 1 description says "This patch is simpler than Chrome OS's glibc patch and makes ELF_DYNAMIC_DO_RELR available to all ports.". What exactly would other architectures need to add in glibc to provide RELR support, since I don't see any actual architecture-specific code in this patch series outside of configure scripts? Please provide text you would propose to add to https://sourceware.org/glibc/wiki/PortStatus that gives an architecture maintainer all the information needed to add such support for their architecture. If in fact no architecture-specific code should be needed, please remove the SUPPORT_DT_RELR handling and just allow glibc to support the feature for all architectures (while using RELR in glibc itself for architectures where the linker support is present, as detected by a configure test on the linker rather than hardcoding information about which architectures have that linker support at a given time). The default should be to support a feature for all architectures. A patch series supporting a feature for only some architectures needs a positive reason for excluding other architectures (for example, that each architecture needs architecture-specific code, for which you provide suitable documentation to add to PortStatus to help architecture maintainers in writing such code).
On Fri, Feb 4, 2022 at 12:00 PM Joseph Myers <joseph@codesourcery.com> wrote: > > On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote: > > > DT_RELR is enabled in glibc shared libraries and position independent > > executables (PIE) automatically if linker supports -z pack-relative-relocs > > nd the architecture defines SUPPORT_DT_RELR in config.h. At the moment, > > only x86 targets define SUPPORT_DT_RELR. > > The patch 1 description says "This patch is simpler than Chrome OS's glibc > patch and makes ELF_DYNAMIC_DO_RELR available to all ports.". > > What exactly would other architectures need to add in glibc to provide > RELR support, since I don't see any actual architecture-specific code in DT_RELR is enabled only if linker supports -z report-relative-reloc option which adds GLIBC_ABI_DT_RELR dependency in the linker output to prevent random crashes with the older glibc binaries. > this patch series outside of configure scripts? Please provide text you > would propose to add to https://sourceware.org/glibc/wiki/PortStatus that > gives an architecture maintainer all the information needed to add such > support for their architecture. If in fact no architecture-specific code > should be needed, please remove the SUPPORT_DT_RELR handling and just > allow glibc to support the feature for all architectures (while using RELR > in glibc itself for architectures where the linker support is present, as > detected by a configure test on the linker rather than hardcoding > information about which architectures have that linker support at a given > time). > > The default should be to support a feature for all architectures. A patch > series supporting a feature for only some architectures needs a positive > reason for excluding other architectures (for example, that each > architecture needs architecture-specific code, for which you provide > suitable documentation to add to PortStatus to help architecture > maintainers in writing such code). > > -- > Joseph S. Myers > joseph@codesourcery.com
On Fri, 4 Feb 2022, H.J. Lu via Libc-alpha wrote: > On Fri, Feb 4, 2022 at 12:00 PM Joseph Myers <joseph@codesourcery.com> wrote: > > > > On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote: > > > > > DT_RELR is enabled in glibc shared libraries and position independent > > > executables (PIE) automatically if linker supports -z pack-relative-relocs > > > nd the architecture defines SUPPORT_DT_RELR in config.h. At the moment, > > > only x86 targets define SUPPORT_DT_RELR. > > > > The patch 1 description says "This patch is simpler than Chrome OS's glibc > > patch and makes ELF_DYNAMIC_DO_RELR available to all ports.". > > > > What exactly would other architectures need to add in glibc to provide > > RELR support, since I don't see any actual architecture-specific code in > > DT_RELR is enabled only if linker supports -z report-relative-reloc option > which adds GLIBC_ABI_DT_RELR dependency in the linker output to > prevent random crashes with the older glibc binaries. What do you mean by "is enabled"? Building glibc itself to use such relocations can properly depend on linker support. The set of binaries (executables and shared libraries) glibc can load must not depend on linker support. Those are two different questions.
On 2022-02-04, Joseph Myers wrote: >On Thu, 3 Feb 2022, H.J. Lu via Libc-alpha wrote: > >> DT_RELR is enabled in glibc shared libraries and position independent >> executables (PIE) automatically if linker supports -z pack-relative-relocs >> nd the architecture defines SUPPORT_DT_RELR in config.h. At the moment, >> only x86 targets define SUPPORT_DT_RELR. > >The patch 1 description says "This patch is simpler than Chrome OS's glibc >patch and makes ELF_DYNAMIC_DO_RELR available to all ports.". > >What exactly would other architectures need to add in glibc to provide >RELR support, since I don't see any actual architecture-specific code in >this patch series outside of configure scripts? Please provide text you >would propose to add to https://sourceware.org/glibc/wiki/PortStatus that >gives an architecture maintainer all the information needed to add such >support for their architecture. If in fact no architecture-specific code >should be needed, please remove the SUPPORT_DT_RELR handling and just >allow glibc to support the feature for all architectures (while using RELR >in glibc itself for architectures where the linker support is present, as >detected by a configure test on the linker rather than hardcoding >information about which architectures have that linker support at a given >time). > >The default should be to support a feature for all architectures. A patch >series supporting a feature for only some architectures needs a positive >reason for excluding other architectures (for example, that each >architecture needs architecture-specific code, for which you provide >suitable documentation to add to PortStatus to help architecture >maintainers in writing such code). The patch series mix two things. "elf: Support DT_RELR relative relocation format [BZ #27924]" allows user programs to use DT_RELR. This is the main benefit. AIUI the other patches are to allow x86-64 libc.so.6 to be built with DT_RELR. This is more for dogfooding purposes and helps binutils port maintainers confirm their ld.bfd support handles some uncommon cases (glibc shared objects). The second part needs a https://sourceware.org/glibc/wiki/PortStatus entry. --- (Personally I'd prefer separate patches. But with some frustration on https://sourceware.org/pipermail/libc-alpha/2021-November/133009.html I don't care in what form glibc will get DT_RELR support... and I really appreciate that H.J contributed the ld.bfd support and drives this glibc effort. )