Indirect External Access

mentioned in issue x86-64-ABI#8 (closed)

I looked at the wiki and have the following comments.

Now that this is x86-64-specific, I think function descriptors should be mentioned.
For the same reason, it should be possible to mention concrete relocation types.
I think it should be possible to make a large set of existing objects (without additional markup) provably compatible with the new way of doing things, based on the relocations they use and the symbols they reference.
I do not think generic GNU properties and automatic OR/AND combinations are a good fit here. Compatibility of objects depends on relocations and referenced symbols. Coarse processing at the object-file level does not seem particularly helpful.

Ideally, I would like to have something that could one day replace the hidden aliases we use for internal symbol references inside glibc. However, that will probably need a mechanism to turn STV_PROTECTED into STV_DEFAULT at final link, given that for most symbols, we do not actually care that the canonical address is different outside of glibc (and our hidden prototypes frequently cause this today).

The function pointer issue applies to systems without function descriptor, which is mentioned in the wiki page.
The COPY relocation issue isn't unique to x86. The following targets have COPY relocation in glibc:

aarch64/dl-machine.h:   | (((type) == AARCH64_R(COPY)) * ELF_RTYPE_CLASS_COPY)	\
arc/dl-machine.h:   | (((type) == R_ARC_COPY) * ELF_RTYPE_CLASS_COPY))
arm/dl-machine.h:   | (((type) == R_ARM_COPY) * ELF_RTYPE_CLASS_COPY)		\
arm/dl-machine.h:   | (((type) == R_ARM_COPY) * ELF_RTYPE_CLASS_COPY)	\
csky/dl-machine.h:   | (((type) == R_CKCORE_COPY) * ELF_RTYPE_CLASS_COPY))
csky/dl-machine.h:   | (((type) == R_CKCORE_COPY) * ELF_RTYPE_CLASS_COPY))
hppa/dl-machine.h:  | (((type) == R_PARISC_COPY) * ELF_RTYPE_CLASS_COPY))
hppa/dl-machine.h:   | (((type) == R_PARISC_COPY) * ELF_RTYPE_CLASS_COPY))
i386/dl-machine.h:   | (((type) == R_386_COPY) * ELF_RTYPE_CLASS_COPY)		      \
m68k/dl-machine.h:   | (((type) == R_68K_COPY) * ELF_RTYPE_CLASS_COPY))
microblaze/dl-machine.h:   | ((type) == R_MICROBLAZE_COPY) * ELF_RTYPE_CLASS_COPY)
microblaze/dl-machine.h:   | ((type) == R_MICROBLAZE_COPY) * ELF_RTYPE_CLASS_COPY)
mips/dl-machine.h:   | (((type) == R_MIPS_COPY) * ELF_RTYPE_CLASS_COPY))
nios2/dl-machine.h:   | (((type) == R_NIOS2_COPY) * ELF_RTYPE_CLASS_COPY)	\
powerpc/powerpc32/dl-machine.h:   | (((type) == R_PPC_COPY) * ELF_RTYPE_CLASS_COPY))
powerpc/powerpc64/dl-machine.h:  (ELF_RTYPE_CLASS_PLT | (((type) == R_PPC64_COPY) * ELF_RTYPE_CLASS_COPY))
powerpc/powerpc64/dl-machine.h:   | (((type) == R_PPC64_COPY) * ELF_RTYPE_CLASS_COPY))
riscv/dl-machine.h:   | (ELF_RTYPE_CLASS_COPY * ((type) == R_RISCV_COPY)))
s390/s390-32/dl-machine.h:   | (((type) == R_390_COPY) * ELF_RTYPE_CLASS_COPY))
s390/s390-64/dl-machine.h:   | (((type) == R_390_COPY) * ELF_RTYPE_CLASS_COPY))
sh/dl-machine.h:   | (((type) == R_SH_COPY) * ELF_RTYPE_CLASS_COPY))
sparc/sparc32/dl-machine.h:   | (((type) == R_SPARC_COPY) * ELF_RTYPE_CLASS_COPY))
sparc/sparc64/dl-machine.h:   | (((type) == R_SPARC_COPY) * ELF_RTYPE_CLASS_COPY))
x86_64/dl-machine.h:   | (((type) == R_X86_64_COPY) * ELF_RTYPE_CLASS_COPY)	      \

Action of linker and dynamic linker is always per-relocation. The property marker is used in the following ways:
Linker can decide the best way to resolve a relocation against a protected symbol BEFORE seeing ALL relocations against the symbol.
Dynamic linker can decide if it is an error to have a copy relocation against the protected symbol based on if the shared library is built with -fno-direct-extern-access.
FUNC symbols can be made protected with -fno-direct-extern-access. With the property marker, we don't need to turn STV_PROTECTED FUNC symbols into STV_DEFAULT.

Indirect External Access

Designs

Child items ...

Activity