| Message ID | 20210923020207.1414230-1-hjl.tools@gmail.com |
|---|---|
| Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.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 A08D23857C4C for <patchwork@sourceware.org>; Thu, 23 Sep 2021 02:03:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A08D23857C4C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1632362610; bh=TG+EYiSqf5qrXWxvl/CkMk90zxP8Dm//QtBz3vX4Foc=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:Cc:From; b=s/EXc5jUYgQ4FmjpnbXUIh9zfefnsd2l/ii0QoMj2Y30U5OIXzzWHWjDyrqVVQ0M8 34RLuyaUY1s4lba0pfO2rgBYP1ai4VMIisYJv1g9ZJl5HXI90iLX7Dc8gA4N+MgCRG 3pXEylhMYEiyB6avmj+XsU4qKuq2wf6IzzQBudag= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id BBF063857C4A for <gcc-patches@gcc.gnu.org>; Thu, 23 Sep 2021 02:02:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BBF063857C4A Received: by mail-pl1-x62b.google.com with SMTP id j14so3014182plx.4 for <gcc-patches@gcc.gnu.org>; Wed, 22 Sep 2021 19:02:18 -0700 (PDT) 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=TG+EYiSqf5qrXWxvl/CkMk90zxP8Dm//QtBz3vX4Foc=; b=3tgtF/y009PeXkGPf5UWAx3F8GnBRMvyc/oE671suwnP+FVpHx382OnhiSyeFtq1Ms t5eY/0GVG5WvSNbrHsoIfuN8vK/DO5gE8ruTBmcqydeqIA3Fce/bHUCkfC00hmQg1UcN fEUSgvQp4eamqBqcKPbn7qKatAxI6kUa/OHhlXtW0C+cEgte0w0npbW1Z39/VWNRvT7m bEd28JWhXzB8CUmsYjzWytLXomOG7uz9eax0yx5hYWiqi/wIsq439WAteIh9WwCB24M+ YBhc2/58iZPNiYKaQGTZlOg0na1ORZZtnpCjnEuJmW3z877PCjMiMVOpLVQWdir/zCSQ 1Tmw== X-Gm-Message-State: AOAM53363vywsSZokt6tFYvYkPG4i/6R0cqt7eaCrS0/CTD0bl5WZzd5 GWnnlZ4azqwW38x2kJJXwO1f1irNx64= X-Google-Smtp-Source: ABdhPJzWIkNCZQAYCyMD4Nv4iXp71M5aJkyuWmHEGduxEVjgfKbRfZRbVINBPdxrvfhHWPRx3gN0AQ== X-Received: by 2002:a17:90a:31cf:: with SMTP id j15mr2438799pjf.86.1632362537291; Wed, 22 Sep 2021 19:02:17 -0700 (PDT) Received: from gnu-gram-1.localdomain (cpe-76-173-15-247.hawaii.res.rr.com. [76.173.15.247]) by smtp.gmail.com with ESMTPSA id nm23sm3568399pjb.26.2021.09.22.19.02.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Sep 2021 19:02:16 -0700 (PDT) Received: from gnu-gram-1.localdomain (localhost [IPv6:::1]) by gnu-gram-1.localdomain (Postfix) with ESMTP id 12C80E0072; Wed, 22 Sep 2021 19:02:15 -0700 (PDT) To: gcc-patches@gcc.gnu.org Subject: [PATCH v4 0/2] Implement indirect external access Date: Wed, 22 Sep 2021 19:02:05 -0700 Message-Id: <20210923020207.1414230-1-hjl.tools@gmail.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3026.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: "H.J. Lu via Gcc-patches" <gcc-patches@gcc.gnu.org> Reply-To: "H.J. Lu" <hjl.tools@gmail.com> Cc: Florian Weimer <fweimer@redhat.com>, Jakub Jelinek <jakub@redhat.com> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
| Series |
Implement indirect external access
|
|
Message
H.J. Lu
Sept. 23, 2021, 2:02 a.m. UTC
Changes in the v4 patch. 1. Add nodirect_extern_access attribute. Changes in the v3 patch. 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to GNU binutils 2.38. But the -z indirect-extern-access linker option is only available for Linux/x86. However, the --max-cache-size=SIZE linker option was also addded within a day. --max-cache-size=SIZE is used to check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. Changes in the v2 patch. 1. Rename the option to -fdirect-extern-access. --- On systems with copy relocation: * A copy in executable is created for the definition in a shared library at run-time by ld.so. * The copy is referenced by executable and shared libraries. * Executable can access the copy directly. Issues are: * Overhead of a copy, time and space, may be visible at run-time. * Read-only data in the shared library becomes read-write copy in executable at run-time. * Local access to data with the STV_PROTECTED visibility in the shared library must use GOT. On systems without function descriptor, function pointers vary depending on where and how the functions are defined. * If the function is defined in executable, it can be the address of function body. * If the function, including the function with STV_PROTECTED visibility, is defined in the shared library, it can be the address of the PLT entry in executable or shared library. Issues are: * The address of function body may not be used as its function pointer. * ld.so needs to search loaded shared libraries for the function pointer of the function with STV_PROTECTED visibility. Here is a proposal to remove copy relocation and use canonical function pointer: 1. Accesses, including in PIE and non-PIE, to undefined symbols must use GOT. a. Linker may optimize out GOT access if the data is defined in PIE or non-PIE. 2. Read-only data in the shared library remain read-only at run-time 3. Address of global data with the STV_PROTECTED visibility in the shared library is the address of data body. a. Can use IP-relative access. b. May need GOT without IP-relative access. 4. For systems without function descriptor, a. All global function pointers of undefined functions in PIE and non-PIE must use GOT. Linker may optimize out GOT access if the function is defined in PIE or non-PIE. b. Function pointer of functions with the STV_PROTECTED visibility in executable and shared library is the address of function body. i. Can use IP-relative access. ii. May need GOT without IP-relative access. iii. Branches to undefined functions may use PLT. 5. Single global definition marker: Add GNU_PROPERTY_1_NEEDED: #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO to indicate the needed properties by the object file. Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) to indicate that the object file requires canonical function pointers and cannot be used with copy relocation. This bit should be cleared in executable when there are non-GOT or non-PLT relocations in relocatable input files without this bit set. a. Protected symbol access within the shared library can be treated as local. b. Copy relocation should be disallowed at link-time and run-time. c. GOT function pointer reference is required at link-time and run-time. The indirect external access marker can be used in the following ways: 1. Linker can decide the best way to resolve a relocation against a protected symbol before seeing all relocations against the symbol. 2. Dynamic linker can decide if it is an error to have a copy relocation in executable against the protected symbol in a shared library by checking if the shared library is built with -fno-direct-extern-access. Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is the default. With -fno-direct-extern-access: 1. Always to use GOT to access undefined symbols, including in PIE and non-PIE. This is safe to do and does not break the ABI. 2. In executable and shared library, for symbols with the STV_PROTECTED visibility: a. The address of data symbol is the address of data body. b. For systems without function descriptor, the function pointer is the address of function body. These break the ABI and resulting shared libraries may not be compatible with executables which are not compiled with -fno-direct-extern-access. 3. Generate an indirect external access marker in relocatable objects if supported by linker. H.J. Lu (2): Add -f[no-]direct-extern-access Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE gcc/c-family/c-attribs.c | 34 +++++++++++ gcc/common.opt | 4 ++ gcc/config.in | 7 +++ gcc/config/i386/gnu-property.c | 31 ---------- gcc/config/i386/i386-protos.h | 2 +- gcc/config/i386/i386.c | 64 ++++++++++++++++----- gcc/configure | 27 +++++++++ gcc/configure.ac | 23 ++++++++ gcc/doc/extend.texi | 6 ++ gcc/doc/invoke.texi | 13 +++++ gcc/doc/tm.texi | 5 ++ gcc/doc/tm.texi.in | 2 + gcc/output.h | 2 + gcc/target.def | 8 +++ gcc/testsuite/g++.dg/pr35513-1.C | 25 ++++++++ gcc/testsuite/g++.dg/pr35513-2.C | 53 +++++++++++++++++ gcc/testsuite/gcc.target/i386/pr35513-10a.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-10b.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-11a.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-11b.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-12a.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-12b.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-1a.c | 16 ++++++ gcc/testsuite/gcc.target/i386/pr35513-1b.c | 16 ++++++ gcc/testsuite/gcc.target/i386/pr35513-2a.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-2b.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-3a.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-3b.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-4a.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-4b.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-5a.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-5b.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-6a.c | 14 +++++ gcc/testsuite/gcc.target/i386/pr35513-6b.c | 14 +++++ gcc/testsuite/gcc.target/i386/pr35513-7a.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-7b.c | 15 +++++ gcc/testsuite/gcc.target/i386/pr35513-8.c | 41 +++++++++++++ gcc/testsuite/gcc.target/i386/pr35513-9a.c | 17 ++++++ gcc/testsuite/gcc.target/i386/pr35513-9b.c | 17 ++++++ gcc/toplev.c | 3 + gcc/varasm.c | 47 +++++++++++++++ 41 files changed, 697 insertions(+), 46 deletions(-) create mode 100644 gcc/testsuite/g++.dg/pr35513-1.C create mode 100644 gcc/testsuite/g++.dg/pr35513-2.C create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-10a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-10b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-11a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-11b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-12a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-12b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-1a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-1b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-2a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-2b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-3a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-3b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-4a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-4b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-5a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-5b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-6a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-6b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-7a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-7b.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-8.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-9a.c create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-9b.c
Comments
On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > Changes in the v4 patch. > > 1. Add nodirect_extern_access attribute. > > Changes in the v3 patch. > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > GNU binutils 2.38. But the -z indirect-extern-access linker option is > only available for Linux/x86. However, the --max-cache-size=SIZE linker > option was also addded within a day. --max-cache-size=SIZE is used to > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > Changes in the v2 patch. > > 1. Rename the option to -fdirect-extern-access. > > --- > On systems with copy relocation: > * A copy in executable is created for the definition in a shared library > at run-time by ld.so. > * The copy is referenced by executable and shared libraries. > * Executable can access the copy directly. > > Issues are: > * Overhead of a copy, time and space, may be visible at run-time. > * Read-only data in the shared library becomes read-write copy in > executable at run-time. > * Local access to data with the STV_PROTECTED visibility in the shared > library must use GOT. > > On systems without function descriptor, function pointers vary depending > on where and how the functions are defined. > * If the function is defined in executable, it can be the address of > function body. > * If the function, including the function with STV_PROTECTED visibility, > is defined in the shared library, it can be the address of the PLT entry > in executable or shared library. > > Issues are: > * The address of function body may not be used as its function pointer. > * ld.so needs to search loaded shared libraries for the function pointer > of the function with STV_PROTECTED visibility. > > Here is a proposal to remove copy relocation and use canonical function > pointer: > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > use GOT. > a. Linker may optimize out GOT access if the data is defined in PIE or > non-PIE. > 2. Read-only data in the shared library remain read-only at run-time > 3. Address of global data with the STV_PROTECTED visibility in the shared > library is the address of data body. > a. Can use IP-relative access. > b. May need GOT without IP-relative access. > 4. For systems without function descriptor, > a. All global function pointers of undefined functions in PIE and > non-PIE must use GOT. Linker may optimize out GOT access if the > function is defined in PIE or non-PIE. > b. Function pointer of functions with the STV_PROTECTED visibility in > executable and shared library is the address of function body. > i. Can use IP-relative access. > ii. May need GOT without IP-relative access. > iii. Branches to undefined functions may use PLT. > 5. Single global definition marker: > > Add GNU_PROPERTY_1_NEEDED: > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > to indicate the needed properties by the object file. > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > to indicate that the object file requires canonical function pointers and > cannot be used with copy relocation. This bit should be cleared in > executable when there are non-GOT or non-PLT relocations in relocatable > input files without this bit set. > > a. Protected symbol access within the shared library can be treated as > local. > b. Copy relocation should be disallowed at link-time and run-time. > c. GOT function pointer reference is required at link-time and run-time. > > The indirect external access marker can be used in the following ways: > > 1. Linker can decide the best way to resolve a relocation against a > protected symbol before seeing all relocations against the symbol. > 2. Dynamic linker can decide if it is an error to have a copy relocation > in executable against the protected symbol in a shared library by checking > if the shared library is built with -fno-direct-extern-access. > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > the default. With -fno-direct-extern-access: > > 1. Always to use GOT to access undefined symbols, including in PIE and > non-PIE. This is safe to do and does not break the ABI. > 2. In executable and shared library, for symbols with the STV_PROTECTED > visibility: > a. The address of data symbol is the address of data body. > b. For systems without function descriptor, the function pointer is > the address of function body. > These break the ABI and resulting shared libraries may not be compatible > with executables which are not compiled with -fno-direct-extern-access. > 3. Generate an indirect external access marker in relocatable objects if > supported by linker. > > H.J. Lu (2): > Add -f[no-]direct-extern-access > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > Hi, This has been implemented in binutils 2.38 and glibc 2.35. What do I need to do to get it into GCC 12? Thanks.
On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > Changes in the v4 patch. > > > > 1. Add nodirect_extern_access attribute. > > > > Changes in the v3 patch. > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > only available for Linux/x86. However, the --max-cache-size=SIZE linker > > option was also addded within a day. --max-cache-size=SIZE is used to > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > Changes in the v2 patch. > > > > 1. Rename the option to -fdirect-extern-access. > > > > --- > > On systems with copy relocation: > > * A copy in executable is created for the definition in a shared library > > at run-time by ld.so. > > * The copy is referenced by executable and shared libraries. > > * Executable can access the copy directly. > > > > Issues are: > > * Overhead of a copy, time and space, may be visible at run-time. > > * Read-only data in the shared library becomes read-write copy in > > executable at run-time. > > * Local access to data with the STV_PROTECTED visibility in the shared > > library must use GOT. > > > > On systems without function descriptor, function pointers vary depending > > on where and how the functions are defined. > > * If the function is defined in executable, it can be the address of > > function body. > > * If the function, including the function with STV_PROTECTED visibility, > > is defined in the shared library, it can be the address of the PLT entry > > in executable or shared library. > > > > Issues are: > > * The address of function body may not be used as its function pointer. > > * ld.so needs to search loaded shared libraries for the function pointer > > of the function with STV_PROTECTED visibility. > > > > Here is a proposal to remove copy relocation and use canonical function > > pointer: > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > use GOT. > > a. Linker may optimize out GOT access if the data is defined in PIE or > > non-PIE. > > 2. Read-only data in the shared library remain read-only at run-time > > 3. Address of global data with the STV_PROTECTED visibility in the shared > > library is the address of data body. > > a. Can use IP-relative access. > > b. May need GOT without IP-relative access. > > 4. For systems without function descriptor, > > a. All global function pointers of undefined functions in PIE and > > non-PIE must use GOT. Linker may optimize out GOT access if the > > function is defined in PIE or non-PIE. > > b. Function pointer of functions with the STV_PROTECTED visibility in > > executable and shared library is the address of function body. > > i. Can use IP-relative access. > > ii. May need GOT without IP-relative access. > > iii. Branches to undefined functions may use PLT. > > 5. Single global definition marker: > > > > Add GNU_PROPERTY_1_NEEDED: > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > to indicate the needed properties by the object file. > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > to indicate that the object file requires canonical function pointers and > > cannot be used with copy relocation. This bit should be cleared in > > executable when there are non-GOT or non-PLT relocations in relocatable > > input files without this bit set. > > > > a. Protected symbol access within the shared library can be treated as > > local. > > b. Copy relocation should be disallowed at link-time and run-time. > > c. GOT function pointer reference is required at link-time and run-time. > > > > The indirect external access marker can be used in the following ways: > > > > 1. Linker can decide the best way to resolve a relocation against a > > protected symbol before seeing all relocations against the symbol. > > 2. Dynamic linker can decide if it is an error to have a copy relocation > > in executable against the protected symbol in a shared library by checking > > if the shared library is built with -fno-direct-extern-access. > > > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > > the default. With -fno-direct-extern-access: > > > > 1. Always to use GOT to access undefined symbols, including in PIE and > > non-PIE. This is safe to do and does not break the ABI. > > 2. In executable and shared library, for symbols with the STV_PROTECTED > > visibility: > > a. The address of data symbol is the address of data body. > > b. For systems without function descriptor, the function pointer is > > the address of function body. > > These break the ABI and resulting shared libraries may not be compatible > > with executables which are not compiled with -fno-direct-extern-access. > > 3. Generate an indirect external access marker in relocatable objects if > > supported by linker. > > > > H.J. Lu (2): > > Add -f[no-]direct-extern-access > > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > > > > Hi, > > This has been implemented in binutils 2.38 and glibc 2.35. > What do I need to do to get it into GCC 12? > Hi Richard, Jeff, Can you help review this patch for GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580108.html https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580107.html Thanks.
On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > Changes in the v4 patch. > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > Changes in the v3 patch. > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > > only available for Linux/x86. However, the --max-cache-size=SIZE linker > > > option was also addded within a day. --max-cache-size=SIZE is used to > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > Changes in the v2 patch. > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > --- > > > On systems with copy relocation: > > > * A copy in executable is created for the definition in a shared library > > > at run-time by ld.so. > > > * The copy is referenced by executable and shared libraries. > > > * Executable can access the copy directly. > > > > > > Issues are: > > > * Overhead of a copy, time and space, may be visible at run-time. > > > * Read-only data in the shared library becomes read-write copy in > > > executable at run-time. > > > * Local access to data with the STV_PROTECTED visibility in the shared > > > library must use GOT. > > > > > > On systems without function descriptor, function pointers vary depending > > > on where and how the functions are defined. > > > * If the function is defined in executable, it can be the address of > > > function body. > > > * If the function, including the function with STV_PROTECTED visibility, > > > is defined in the shared library, it can be the address of the PLT entry > > > in executable or shared library. > > > > > > Issues are: > > > * The address of function body may not be used as its function pointer. > > > * ld.so needs to search loaded shared libraries for the function pointer > > > of the function with STV_PROTECTED visibility. > > > > > > Here is a proposal to remove copy relocation and use canonical function > > > pointer: > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > use GOT. > > > a. Linker may optimize out GOT access if the data is defined in PIE or > > > non-PIE. > > > 2. Read-only data in the shared library remain read-only at run-time > > > 3. Address of global data with the STV_PROTECTED visibility in the shared > > > library is the address of data body. > > > a. Can use IP-relative access. > > > b. May need GOT without IP-relative access. > > > 4. For systems without function descriptor, > > > a. All global function pointers of undefined functions in PIE and > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > function is defined in PIE or non-PIE. > > > b. Function pointer of functions with the STV_PROTECTED visibility in > > > executable and shared library is the address of function body. > > > i. Can use IP-relative access. > > > ii. May need GOT without IP-relative access. > > > iii. Branches to undefined functions may use PLT. > > > 5. Single global definition marker: > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > to indicate the needed properties by the object file. > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > to indicate that the object file requires canonical function pointers and > > > cannot be used with copy relocation. This bit should be cleared in > > > executable when there are non-GOT or non-PLT relocations in relocatable > > > input files without this bit set. > > > > > > a. Protected symbol access within the shared library can be treated as > > > local. > > > b. Copy relocation should be disallowed at link-time and run-time. > > > c. GOT function pointer reference is required at link-time and run-time. > > > > > > The indirect external access marker can be used in the following ways: > > > > > > 1. Linker can decide the best way to resolve a relocation against a > > > protected symbol before seeing all relocations against the symbol. > > > 2. Dynamic linker can decide if it is an error to have a copy relocation > > > in executable against the protected symbol in a shared library by checking > > > if the shared library is built with -fno-direct-extern-access. > > > > > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > > > the default. With -fno-direct-extern-access: > > > > > > 1. Always to use GOT to access undefined symbols, including in PIE and > > > non-PIE. This is safe to do and does not break the ABI. > > > 2. In executable and shared library, for symbols with the STV_PROTECTED > > > visibility: > > > a. The address of data symbol is the address of data body. > > > b. For systems without function descriptor, the function pointer is > > > the address of function body. > > > These break the ABI and resulting shared libraries may not be compatible > > > with executables which are not compiled with -fno-direct-extern-access. > > > 3. Generate an indirect external access marker in relocatable objects if > > > supported by linker. > > > > > > H.J. Lu (2): > > > Add -f[no-]direct-extern-access > > > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > > > > > > > Hi, > > > > This has been implemented in binutils 2.38 and glibc 2.35. > > What do I need to do to get it into GCC 12? > > > > Hi Richard, Jeff, > > Can you help review this patch for GCC 12: > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580108.html > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580107.html > PING.
On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > Changes in the v4 patch. > > > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > > > Changes in the v3 patch. > > > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > > > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > > > only available for Linux/x86. However, the --max-cache-size=SIZE linker > > > > option was also addded within a day. --max-cache-size=SIZE is used to > > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > > > Changes in the v2 patch. > > > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > > > --- > > > > On systems with copy relocation: > > > > * A copy in executable is created for the definition in a shared library > > > > at run-time by ld.so. > > > > * The copy is referenced by executable and shared libraries. > > > > * Executable can access the copy directly. > > > > > > > > Issues are: > > > > * Overhead of a copy, time and space, may be visible at run-time. > > > > * Read-only data in the shared library becomes read-write copy in > > > > executable at run-time. > > > > * Local access to data with the STV_PROTECTED visibility in the shared > > > > library must use GOT. > > > > > > > > On systems without function descriptor, function pointers vary depending > > > > on where and how the functions are defined. > > > > * If the function is defined in executable, it can be the address of > > > > function body. > > > > * If the function, including the function with STV_PROTECTED visibility, > > > > is defined in the shared library, it can be the address of the PLT entry > > > > in executable or shared library. > > > > > > > > Issues are: > > > > * The address of function body may not be used as its function pointer. > > > > * ld.so needs to search loaded shared libraries for the function pointer > > > > of the function with STV_PROTECTED visibility. > > > > > > > > Here is a proposal to remove copy relocation and use canonical function > > > > pointer: > > > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > > use GOT. > > > > a. Linker may optimize out GOT access if the data is defined in PIE or > > > > non-PIE. > > > > 2. Read-only data in the shared library remain read-only at run-time > > > > 3. Address of global data with the STV_PROTECTED visibility in the shared > > > > library is the address of data body. > > > > a. Can use IP-relative access. > > > > b. May need GOT without IP-relative access. > > > > 4. For systems without function descriptor, > > > > a. All global function pointers of undefined functions in PIE and > > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > > function is defined in PIE or non-PIE. > > > > b. Function pointer of functions with the STV_PROTECTED visibility in > > > > executable and shared library is the address of function body. > > > > i. Can use IP-relative access. > > > > ii. May need GOT without IP-relative access. > > > > iii. Branches to undefined functions may use PLT. > > > > 5. Single global definition marker: > > > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > > > to indicate the needed properties by the object file. > > > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > > > to indicate that the object file requires canonical function pointers and > > > > cannot be used with copy relocation. This bit should be cleared in > > > > executable when there are non-GOT or non-PLT relocations in relocatable > > > > input files without this bit set. > > > > > > > > a. Protected symbol access within the shared library can be treated as > > > > local. > > > > b. Copy relocation should be disallowed at link-time and run-time. > > > > c. GOT function pointer reference is required at link-time and run-time. > > > > > > > > The indirect external access marker can be used in the following ways: > > > > > > > > 1. Linker can decide the best way to resolve a relocation against a > > > > protected symbol before seeing all relocations against the symbol. > > > > 2. Dynamic linker can decide if it is an error to have a copy relocation > > > > in executable against the protected symbol in a shared library by checking > > > > if the shared library is built with -fno-direct-extern-access. > > > > > > > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > > > > the default. With -fno-direct-extern-access: > > > > > > > > 1. Always to use GOT to access undefined symbols, including in PIE and > > > > non-PIE. This is safe to do and does not break the ABI. > > > > 2. In executable and shared library, for symbols with the STV_PROTECTED > > > > visibility: > > > > a. The address of data symbol is the address of data body. > > > > b. For systems without function descriptor, the function pointer is > > > > the address of function body. > > > > These break the ABI and resulting shared libraries may not be compatible > > > > with executables which are not compiled with -fno-direct-extern-access. > > > > 3. Generate an indirect external access marker in relocatable objects if > > > > supported by linker. > > > > > > > > H.J. Lu (2): > > > > Add -f[no-]direct-extern-access > > > > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > > > > > > > > > > Hi, > > > > > > This has been implemented in binutils 2.38 and glibc 2.35. > > > What do I need to do to get it into GCC 12? > > > > > > > Hi Richard, Jeff, > > > > Can you help review this patch for GCC 12: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580108.html > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580107.html > > > > PING. PING.
On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > > > Changes in the v4 patch. > > > > > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > > > > > Changes in the v3 patch. > > > > > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > > > > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > > > > only available for Linux/x86. However, the --max-cache-size=SIZE linker > > > > > option was also addded within a day. --max-cache-size=SIZE is used to > > > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > > > > > Changes in the v2 patch. > > > > > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > > > > > --- > > > > > On systems with copy relocation: > > > > > * A copy in executable is created for the definition in a shared library > > > > > at run-time by ld.so. > > > > > * The copy is referenced by executable and shared libraries. > > > > > * Executable can access the copy directly. > > > > > > > > > > Issues are: > > > > > * Overhead of a copy, time and space, may be visible at run-time. > > > > > * Read-only data in the shared library becomes read-write copy in > > > > > executable at run-time. > > > > > * Local access to data with the STV_PROTECTED visibility in the shared > > > > > library must use GOT. > > > > > > > > > > On systems without function descriptor, function pointers vary depending > > > > > on where and how the functions are defined. > > > > > * If the function is defined in executable, it can be the address of > > > > > function body. > > > > > * If the function, including the function with STV_PROTECTED visibility, > > > > > is defined in the shared library, it can be the address of the PLT entry > > > > > in executable or shared library. > > > > > > > > > > Issues are: > > > > > * The address of function body may not be used as its function pointer. > > > > > * ld.so needs to search loaded shared libraries for the function pointer > > > > > of the function with STV_PROTECTED visibility. > > > > > > > > > > Here is a proposal to remove copy relocation and use canonical function > > > > > pointer: > > > > > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > > > use GOT. > > > > > a. Linker may optimize out GOT access if the data is defined in PIE or > > > > > non-PIE. > > > > > 2. Read-only data in the shared library remain read-only at run-time > > > > > 3. Address of global data with the STV_PROTECTED visibility in the shared > > > > > library is the address of data body. > > > > > a. Can use IP-relative access. > > > > > b. May need GOT without IP-relative access. > > > > > 4. For systems without function descriptor, > > > > > a. All global function pointers of undefined functions in PIE and > > > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > > > function is defined in PIE or non-PIE. > > > > > b. Function pointer of functions with the STV_PROTECTED visibility in > > > > > executable and shared library is the address of function body. > > > > > i. Can use IP-relative access. > > > > > ii. May need GOT without IP-relative access. > > > > > iii. Branches to undefined functions may use PLT. > > > > > 5. Single global definition marker: > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > > > > > to indicate the needed properties by the object file. > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > > > > > to indicate that the object file requires canonical function pointers and > > > > > cannot be used with copy relocation. This bit should be cleared in > > > > > executable when there are non-GOT or non-PLT relocations in relocatable > > > > > input files without this bit set. > > > > > > > > > > a. Protected symbol access within the shared library can be treated as > > > > > local. > > > > > b. Copy relocation should be disallowed at link-time and run-time. > > > > > c. GOT function pointer reference is required at link-time and run-time. > > > > > > > > > > The indirect external access marker can be used in the following ways: > > > > > > > > > > 1. Linker can decide the best way to resolve a relocation against a > > > > > protected symbol before seeing all relocations against the symbol. > > > > > 2. Dynamic linker can decide if it is an error to have a copy relocation > > > > > in executable against the protected symbol in a shared library by checking > > > > > if the shared library is built with -fno-direct-extern-access. > > > > > > > > > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > > > > > the default. With -fno-direct-extern-access: > > > > > > > > > > 1. Always to use GOT to access undefined symbols, including in PIE and > > > > > non-PIE. This is safe to do and does not break the ABI. > > > > > 2. In executable and shared library, for symbols with the STV_PROTECTED > > > > > visibility: > > > > > a. The address of data symbol is the address of data body. > > > > > b. For systems without function descriptor, the function pointer is > > > > > the address of function body. > > > > > These break the ABI and resulting shared libraries may not be compatible > > > > > with executables which are not compiled with -fno-direct-extern-access. > > > > > 3. Generate an indirect external access marker in relocatable objects if > > > > > supported by linker. > > > > > > > > > > H.J. Lu (2): > > > > > Add -f[no-]direct-extern-access > > > > > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > > > > > > > > > > > > > Hi, > > > > > > > > This has been implemented in binutils 2.38 and glibc 2.35. > > > > What do I need to do to get it into GCC 12? > > > > > > > > > > Hi Richard, Jeff, > > > > > > Can you help review this patch for GCC 12: > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580108.html > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580107.html > > > > > > > PING. > > PING. > PING.
Ping, could a global maintainer take a look at this? On Mon, Jan 03, 2022 at 07:32:25PM -0800, H.J. Lu via Gcc-patches wrote: > On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > > > > > Changes in the v4 patch. > > > > > > > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > > > > > > > Changes in the v3 patch. > > > > > > > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > > > > > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > > > > > only available for Linux/x86. However, the --max-cache-size=SIZE linker > > > > > > option was also addded within a day. --max-cache-size=SIZE is used to > > > > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > > > > > > > Changes in the v2 patch. > > > > > > > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > > > > > > > --- > > > > > > On systems with copy relocation: > > > > > > * A copy in executable is created for the definition in a shared library > > > > > > at run-time by ld.so. > > > > > > * The copy is referenced by executable and shared libraries. > > > > > > * Executable can access the copy directly. > > > > > > > > > > > > Issues are: > > > > > > * Overhead of a copy, time and space, may be visible at run-time. > > > > > > * Read-only data in the shared library becomes read-write copy in > > > > > > executable at run-time. > > > > > > * Local access to data with the STV_PROTECTED visibility in the shared > > > > > > library must use GOT. > > > > > > > > > > > > On systems without function descriptor, function pointers vary depending > > > > > > on where and how the functions are defined. > > > > > > * If the function is defined in executable, it can be the address of > > > > > > function body. > > > > > > * If the function, including the function with STV_PROTECTED visibility, > > > > > > is defined in the shared library, it can be the address of the PLT entry > > > > > > in executable or shared library. > > > > > > > > > > > > Issues are: > > > > > > * The address of function body may not be used as its function pointer. > > > > > > * ld.so needs to search loaded shared libraries for the function pointer > > > > > > of the function with STV_PROTECTED visibility. > > > > > > > > > > > > Here is a proposal to remove copy relocation and use canonical function > > > > > > pointer: > > > > > > > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > > > > use GOT. > > > > > > a. Linker may optimize out GOT access if the data is defined in PIE or > > > > > > non-PIE. > > > > > > 2. Read-only data in the shared library remain read-only at run-time > > > > > > 3. Address of global data with the STV_PROTECTED visibility in the shared > > > > > > library is the address of data body. > > > > > > a. Can use IP-relative access. > > > > > > b. May need GOT without IP-relative access. > > > > > > 4. For systems without function descriptor, > > > > > > a. All global function pointers of undefined functions in PIE and > > > > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > > > > function is defined in PIE or non-PIE. > > > > > > b. Function pointer of functions with the STV_PROTECTED visibility in > > > > > > executable and shared library is the address of function body. > > > > > > i. Can use IP-relative access. > > > > > > ii. May need GOT without IP-relative access. > > > > > > iii. Branches to undefined functions may use PLT. > > > > > > 5. Single global definition marker: > > > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > > > > > > > to indicate the needed properties by the object file. > > > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > > > > > > > to indicate that the object file requires canonical function pointers and > > > > > > cannot be used with copy relocation. This bit should be cleared in > > > > > > executable when there are non-GOT or non-PLT relocations in relocatable > > > > > > input files without this bit set. > > > > > > > > > > > > a. Protected symbol access within the shared library can be treated as > > > > > > local. > > > > > > b. Copy relocation should be disallowed at link-time and run-time. > > > > > > c. GOT function pointer reference is required at link-time and run-time. > > > > > > > > > > > > The indirect external access marker can be used in the following ways: > > > > > > > > > > > > 1. Linker can decide the best way to resolve a relocation against a > > > > > > protected symbol before seeing all relocations against the symbol. > > > > > > 2. Dynamic linker can decide if it is an error to have a copy relocation > > > > > > in executable against the protected symbol in a shared library by checking > > > > > > if the shared library is built with -fno-direct-extern-access. > > > > > > > > > > > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > > > > > > the default. With -fno-direct-extern-access: > > > > > > > > > > > > 1. Always to use GOT to access undefined symbols, including in PIE and > > > > > > non-PIE. This is safe to do and does not break the ABI. > > > > > > 2. In executable and shared library, for symbols with the STV_PROTECTED > > > > > > visibility: > > > > > > a. The address of data symbol is the address of data body. > > > > > > b. For systems without function descriptor, the function pointer is > > > > > > the address of function body. > > > > > > These break the ABI and resulting shared libraries may not be compatible > > > > > > with executables which are not compiled with -fno-direct-extern-access. > > > > > > 3. Generate an indirect external access marker in relocatable objects if > > > > > > supported by linker. > > > > > > > > > > > > H.J. Lu (2): > > > > > > Add -f[no-]direct-extern-access > > > > > > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > This has been implemented in binutils 2.38 and glibc 2.35. > > > > > What do I need to do to get it into GCC 12? > > > > > > > > > > > > > Hi Richard, Jeff, > > > > > > > > Can you help review this patch for GCC 12: > > > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580108.html > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580107.html > > > > > > > > > > PING. > > > > PING. > > > > PING. > > > -- > H.J. > Marek
On Mon, Jan 3, 2022 at 7:33 PM H.J. Lu via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > On Sat, Dec 11, 2021 at 10:44 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > On Thu, Nov 25, 2021 at 9:54 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > On Mon, Nov 1, 2021 at 7:02 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > On Thu, Oct 21, 2021 at 12:56 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > > > On Wed, Sep 22, 2021 at 7:02 PM H.J. Lu <hjl.tools@gmail.com> wrote: > > > > > > > > > > > > Changes in the v4 patch. > > > > > > > > > > > > 1. Add nodirect_extern_access attribute. > > > > > > > > > > > > Changes in the v3 patch. > > > > > > > > > > > > 1. GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support has been added to > > > > > > GNU binutils 2.38. But the -z indirect-extern-access linker option is > > > > > > only available for Linux/x86. However, the --max-cache-size=SIZE linker > > > > > > option was also addded within a day. --max-cache-size=SIZE is used to > > > > > > check for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS support. > > > > > > > > > > > > Changes in the v2 patch. > > > > > > > > > > > > 1. Rename the option to -fdirect-extern-access. > > > > > > > > > > > > --- > > > > > > On systems with copy relocation: > > > > > > * A copy in executable is created for the definition in a shared library > > > > > > at run-time by ld.so. > > > > > > * The copy is referenced by executable and shared libraries. > > > > > > * Executable can access the copy directly. > > > > > > > > > > > > Issues are: > > > > > > * Overhead of a copy, time and space, may be visible at run-time. > > > > > > * Read-only data in the shared library becomes read-write copy in > > > > > > executable at run-time. > > > > > > * Local access to data with the STV_PROTECTED visibility in the shared > > > > > > library must use GOT. > > > > > > > > > > > > On systems without function descriptor, function pointers vary depending > > > > > > on where and how the functions are defined. > > > > > > * If the function is defined in executable, it can be the address of > > > > > > function body. > > > > > > * If the function, including the function with STV_PROTECTED visibility, > > > > > > is defined in the shared library, it can be the address of the PLT entry > > > > > > in executable or shared library. > > > > > > > > > > > > Issues are: > > > > > > * The address of function body may not be used as its function pointer. > > > > > > * ld.so needs to search loaded shared libraries for the function pointer > > > > > > of the function with STV_PROTECTED visibility. > > > > > > > > > > > > Here is a proposal to remove copy relocation and use canonical function > > > > > > pointer: > > > > > > > > > > > > 1. Accesses, including in PIE and non-PIE, to undefined symbols must > > > > > > use GOT. > > > > > > a. Linker may optimize out GOT access if the data is defined in PIE or > > > > > > non-PIE. > > > > > > 2. Read-only data in the shared library remain read-only at run-time > > > > > > 3. Address of global data with the STV_PROTECTED visibility in the shared > > > > > > library is the address of data body. > > > > > > a. Can use IP-relative access. > > > > > > b. May need GOT without IP-relative access. > > > > > > 4. For systems without function descriptor, > > > > > > a. All global function pointers of undefined functions in PIE and > > > > > > non-PIE must use GOT. Linker may optimize out GOT access if the > > > > > > function is defined in PIE or non-PIE. > > > > > > b. Function pointer of functions with the STV_PROTECTED visibility in > > > > > > executable and shared library is the address of function body. > > > > > > i. Can use IP-relative access. > > > > > > ii. May need GOT without IP-relative access. > > > > > > iii. Branches to undefined functions may use PLT. > > > > > > 5. Single global definition marker: > > > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED: > > > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > > > > > > > > > > to indicate the needed properties by the object file. > > > > > > > > > > > > Add GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS: > > > > > > > > > > > > #define GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS (1U << 0) > > > > > > > > > > > > to indicate that the object file requires canonical function pointers and > > > > > > cannot be used with copy relocation. This bit should be cleared in > > > > > > executable when there are non-GOT or non-PLT relocations in relocatable > > > > > > input files without this bit set. > > > > > > > > > > > > a. Protected symbol access within the shared library can be treated as > > > > > > local. > > > > > > b. Copy relocation should be disallowed at link-time and run-time. > > > > > > c. GOT function pointer reference is required at link-time and run-time. > > > > > > > > > > > > The indirect external access marker can be used in the following ways: > > > > > > > > > > > > 1. Linker can decide the best way to resolve a relocation against a > > > > > > protected symbol before seeing all relocations against the symbol. > > > > > > 2. Dynamic linker can decide if it is an error to have a copy relocation > > > > > > in executable against the protected symbol in a shared library by checking > > > > > > if the shared library is built with -fno-direct-extern-access. > > > > > > > > > > > > Add a compiler option, -fdirect-extern-access. -fdirect-extern-access is > > > > > > the default. With -fno-direct-extern-access: > > > > > > > > > > > > 1. Always to use GOT to access undefined symbols, including in PIE and > > > > > > non-PIE. This is safe to do and does not break the ABI. > > > > > > 2. In executable and shared library, for symbols with the STV_PROTECTED > > > > > > visibility: > > > > > > a. The address of data symbol is the address of data body. > > > > > > b. For systems without function descriptor, the function pointer is > > > > > > the address of function body. > > > > > > These break the ABI and resulting shared libraries may not be compatible > > > > > > with executables which are not compiled with -fno-direct-extern-access. > > > > > > 3. Generate an indirect external access marker in relocatable objects if > > > > > > supported by linker. > > > > > > > > > > > > H.J. Lu (2): > > > > > > Add -f[no-]direct-extern-access > > > > > > Add TARGET_ASM_EMIT_GNU_PROPERTY_NOTE > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > This has been implemented in binutils 2.38 and glibc 2.35. > > > > > What do I need to do to get it into GCC 12? > > > > > > > > > > > > > Hi Richard, Jeff, > > > > > > > > Can you help review this patch for GCC 12: > > > > > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580108.html > > > > https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580107.html > > > > > > > > > > PING. > > > > PING. > > > > PING. > > > -- > H.J. I'll ping https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570139.html ("[PATCH] x86-64: Remove HAVE_LD_PIE_COPYRELOC"), too. It's somewhat related, but simple and useful on its own.... The -fPIE default for x86-64 should be to avoid PC-relative relocations for extern int x; int foo() { return x; } like -fPIC. There should not be any need to specify a compiler driver option to achieve this goal.