mirrors/musl
1
0
Fork 0
mirror of https://git.musl-libc.org/git/musl synced 2025-02-10 15:24:14 +03:00
Code Issues Packages Projects Releases Wiki Activity
musl/arch/arm/reloc.h

35 lines
777 B
C
Raw Normal View History

make the dynamic linker find its path file relative to its own location prior to this change, using a non-default syslibdir was impractical on systems where the ordinary library paths contain musl-incompatible library files. the file containing search paths was always taken from /etc, which would either correspond to a system-wide musl installation, or fail to exist at all, resulting in searching of the default library path. the new search strategy is safe even for suid programs because the pathname used comes from the PT_INTERP header of the program being run, rather than any external input. as part of this change, I have also begun differentiating the names of arch variants that differ by endianness or floating point calling convention. the corresponding changes in the build system and and gcc wrapper script (to use an alternate dynamic linker name) for these configurations have not yet been made.
2013-07-18 19:29:44 -04:00
#include <endian.h>
first attempt at arm dynamic linking
2011-10-01 00:52:33 -04:00
make the dynamic linker find its path file relative to its own location prior to this change, using a non-default syslibdir was impractical on systems where the ordinary library paths contain musl-incompatible library files. the file containing search paths was always taken from /etc, which would either correspond to a system-wide musl installation, or fail to exist at all, resulting in searching of the default library path. the new search strategy is safe even for suid programs because the pathname used comes from the PT_INTERP header of the program being run, rather than any external input. as part of this change, I have also begun differentiating the names of arch variants that differ by endianness or floating point calling convention. the corresponding changes in the build system and and gcc wrapper script (to use an alternate dynamic linker name) for these configurations have not yet been made.
2013-07-18 19:29:44 -04:00
#if __BYTE_ORDER == __BIG_ENDIAN
#define ENDIAN_SUFFIX "eb"
#else
#define ENDIAN_SUFFIX ""
#endif
fix dynamic linker path file selection for arm vs armhf the __SOFTFP__ macro which was wrongly being used does not reflect the ABI (arm vs armhf) but just the availability of floating point instructions/registers, so -mfloat-abi=softfp was wrongly being treated as armhf. __ARM_PCS_VFP is the correct predefined macro to check for the armhf EABI variant. this macro usage was corrected for the build process in commit 4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56 but reloc.h was apparently overlooked at the time.
2016-01-20 01:16:09 +00:00
#if __ARM_PCS_VFP
make the dynamic linker find its path file relative to its own location prior to this change, using a non-default syslibdir was impractical on systems where the ordinary library paths contain musl-incompatible library files. the file containing search paths was always taken from /etc, which would either correspond to a system-wide musl installation, or fail to exist at all, resulting in searching of the default library path. the new search strategy is safe even for suid programs because the pathname used comes from the PT_INTERP header of the program being run, rather than any external input. as part of this change, I have also begun differentiating the names of arch variants that differ by endianness or floating point calling convention. the corresponding changes in the build system and and gcc wrapper script (to use an alternate dynamic linker name) for these configurations have not yet been made.
2013-07-18 19:29:44 -04:00
#define FP_SUFFIX "hf"
fix dynamic linker path file selection for arm vs armhf the __SOFTFP__ macro which was wrongly being used does not reflect the ABI (arm vs armhf) but just the availability of floating point instructions/registers, so -mfloat-abi=softfp was wrongly being treated as armhf. __ARM_PCS_VFP is the correct predefined macro to check for the armhf EABI variant. this macro usage was corrected for the build process in commit 4918c2bb206bfaaf5a1f7d3448c2f63d5e2b7d56 but reloc.h was apparently overlooked at the time.
2016-01-20 01:16:09 +00:00
#else
#define FP_SUFFIX ""
make the dynamic linker find its path file relative to its own location prior to this change, using a non-default syslibdir was impractical on systems where the ordinary library paths contain musl-incompatible library files. the file containing search paths was always taken from /etc, which would either correspond to a system-wide musl installation, or fail to exist at all, resulting in searching of the default library path. the new search strategy is safe even for suid programs because the pathname used comes from the PT_INTERP header of the program being run, rather than any external input. as part of this change, I have also begun differentiating the names of arch variants that differ by endianness or floating point calling convention. the corresponding changes in the build system and and gcc wrapper script (to use an alternate dynamic linker name) for these configurations have not yet been made.
2013-07-18 19:29:44 -04:00
#endif
#define LDSO_ARCH "arm" ENDIAN_SUFFIX FP_SUFFIX
first attempt at arm dynamic linking
2011-10-01 00:52:33 -04:00
refactor to remove arch-specific relocation code from dynamic linker this was one of the main instances of ugly code duplication: all archs use basically the same types of relocations, but roughly equivalent logic was duplicated for each arch to account for the different naming and numbering of relocation types and variation in whether REL or RELA records are used. as an added bonus, both REL and RELA are now supported on all archs, regardless of which is used by the standard toolchain.
2014-06-18 02:44:02 -04:00
#define NO_LEGACY_INITFINI
fix TLS layout of TLS variant I when there is a gap above TP In TLS variant I the TLS is above TP (or above a fixed offset from TP) but on some targets there is a reserved gap above TP before TLS starts. This matters for the local-exec tls access model when the offsets of TLS variables from the TP are hard coded by the linker into the executable, so the libc must compute these offsets the same way as the linker. The tls offset of the main module has to be alignup(GAP_ABOVE_TP, main_tls_align). If there is no TLS in the main module then the gap can be ignored since musl does not use it and the tls access models of shared libraries are not affected. The previous setup only worked if (tls_align & -GAP_ABOVE_TP) == 0 (i.e. TLS did not require large alignment) because the gap was treated as a fixed offset from TP. Now the TP points at the end of the pthread struct (which is aligned) and there is a gap above it (which may also need alignment). The fix required changing TP_ADJ and __pthread_self on affected targets (aarch64, arm and sh) and in the tlsdesc asm the offset to access the dtv changed too.
2018-06-02 01:52:01 +02:00
#define TPOFF_K 0
first attempt at arm dynamic linking
2011-10-01 00:52:33 -04:00
dynamic linker bootstrap overhaul this overhaul further reduces the amount of arch-specific code needed by the dynamic linker and removes a number of assumptions, including: - that symbolic function references inside libc are bound at link time via the linker option -Bsymbolic-functions. - that libc functions used by the dynamic linker do not require access to data symbols. - that static/internal function calls and data accesses can be made without performing any relocations, or that arch-specific startup code handled any such relocations needed. removing these assumptions paves the way for allowing libc.so itself to be built with stack protector (among other things), and is achieved by a three-stage bootstrap process: 1. relative relocations are processed with a flat function. 2. symbolic relocations are processed with no external calls/data. 3. main program and dependency libs are processed with a fully-functional libc/ldso. reduction in arch-specific code is achived through the following: - crt_arch.h, used for generating crt1.o, now provides the entry point for the dynamic linker too. - asm is no longer responsible for skipping the beginning of argv[] when ldso is invoked as a command. - the functionality previously provided by __reloc_self for heavily GOT-dependent RISC archs is now the arch-agnostic stage-1. - arch-specific relocation type codes are mapped directly as macros rather than via an inline translation function/switch statement.
2015-04-13 02:56:26 -04:00
#define REL_SYMBOLIC R_ARM_ABS32
#define REL_GOT R_ARM_GLOB_DAT
#define REL_PLT R_ARM_JUMP_SLOT
#define REL_RELATIVE R_ARM_RELATIVE
#define REL_COPY R_ARM_COPY
#define REL_DTPMOD R_ARM_TLS_DTPMOD32
#define REL_DTPOFF R_ARM_TLS_DTPOFF32
#define REL_TPOFF R_ARM_TLS_TPOFF32
add TLSDESC support for 32-bit arm unlike other asm where the baseline ISA is used, these functions are hot paths and use ISA-level specializations. call-clobbered vfp registers are saved before calling __tls_get_new, since there is no guarantee it won't use them. while setjmp/longjmp have to use hwcap to decide whether to the fpu is in use, since application code could be using vfp registers even if libc was compiled as pure softfloat, __tls_get_new is part of libc and can be assumed not to have access to vfp registers if tlsdesc.S does not. thus it suffices just to check the predefined preprocessor macros. the check for __ARM_PCS_VFP is redundant; !__SOFTFP__ must always be true if the target ISA level includes fpu instructions/registers.
2018-10-01 18:37:02 -04:00
#define REL_TLSDESC R_ARM_TLS_DESC
#define TLSDESC_BACKWARDS
dynamic linker bootstrap overhaul this overhaul further reduces the amount of arch-specific code needed by the dynamic linker and removes a number of assumptions, including: - that symbolic function references inside libc are bound at link time via the linker option -Bsymbolic-functions. - that libc functions used by the dynamic linker do not require access to data symbols. - that static/internal function calls and data accesses can be made without performing any relocations, or that arch-specific startup code handled any such relocations needed. removing these assumptions paves the way for allowing libc.so itself to be built with stack protector (among other things), and is achieved by a three-stage bootstrap process: 1. relative relocations are processed with a flat function. 2. symbolic relocations are processed with no external calls/data. 3. main program and dependency libs are processed with a fully-functional libc/ldso. reduction in arch-specific code is achived through the following: - crt_arch.h, used for generating crt1.o, now provides the entry point for the dynamic linker too. - asm is no longer responsible for skipping the beginning of argv[] when ldso is invoked as a command. - the functionality previously provided by __reloc_self for heavily GOT-dependent RISC archs is now the arch-agnostic stage-1. - arch-specific relocation type codes are mapped directly as macros rather than via an inline translation function/switch statement.
2015-04-13 02:56:26 -04:00
make arm reloc.h CRTJMP macro compatible with thumb compilers targeting armv7 may be configured to produce thumb2 code instead of arm code by default, and in the future we may wish to support targets where only the thumb instruction set is available. the instructions this patch omits in thumb mode are needed only for non-thumb versions of armv4 or earlier, which are not supported by any current compilers/toolchains and thus rather pointless to have. at some point these compatibility return sequences may be removed from all asm source files, and in that case it would make sense to remove them here too and remove the ifdef.
2015-05-14 18:51:27 -04:00
#define CRTJMP(pc,sp) __asm__ __volatile__( \
"mov sp,%1 ; bx %0" : : "r"(pc), "r"(sp) : "memory" )
Reference in New Issue Copy Permalink