[PATCH v2 0/2] Implement indirect external access

H.J. Lu hjl.tools@gmail.com
Thu Jun 24 13:47:57 GMT 2021

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

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
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:



to indicate the needed properties by the object file.



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
  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
  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

 gcc/common.opt                            |  4 ++
 gcc/config.in                             |  6 +++
 gcc/config/i386/gnu-property.c            | 31 -------------
 gcc/config/i386/i386-protos.h             |  2 +-
 gcc/config/i386/i386.c                    | 52 ++++++++++++++++------
 gcc/configure                             | 24 ++++++++++
 gcc/configure.ac                          | 20 +++++++++
 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-1.c | 16 +++++++
 gcc/testsuite/gcc.target/i386/pr35513-2.c | 15 +++++++
 gcc/testsuite/gcc.target/i386/pr35513-3.c | 15 +++++++
 gcc/testsuite/gcc.target/i386/pr35513-4.c | 15 +++++++
 gcc/testsuite/gcc.target/i386/pr35513-5.c | 15 +++++++
 gcc/testsuite/gcc.target/i386/pr35513-6.c | 14 ++++++
 gcc/testsuite/gcc.target/i386/pr35513-7.c | 15 +++++++
 gcc/testsuite/gcc.target/i386/pr35513-8.c | 41 ++++++++++++++++++
 gcc/toplev.c                              |  3 ++
 gcc/varasm.c                              | 47 ++++++++++++++++++++
 24 files changed, 397 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-1.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-2.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-4.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-5.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-6.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-7.c
 create mode 100644 gcc/testsuite/gcc.target/i386/pr35513-8.c


More information about the Gcc-patches mailing list