about summary refs log tree commit diff
path: root/sysdeps/aarch64/Makefile
Commit message (Collapse)AuthorAgeFilesLines
* aarch64: ensure objects are BTI compatibleSzabolcs Nagy2020-07-081-0/+8
| | | | | | | | | | | | | | | | | | | When glibc is built with branch protection (i.e. with a gcc configured with --enable-standard-branch-protection), all glibc binaries should be BTI compatible and marked as such. It is easy to link BTI incompatible objects by accident and this is silent currently which is usually not the expectation, so this is changed into a link error. (There is no linker flag for failing on BTI incompatible inputs so all warnings are turned into fatal errors outside the test system when building glibc with branch protection.) Unfortunately, outlined atomic functions are not BTI compatible in libgcc (PR libgcc/96001), so to build glibc with current gcc use 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon and then glibc can be built and tested without such workarounds. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: enable BTI at runtimeSudakshina Das2020-07-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Binaries can opt-in to using BTI via an ELF object file marking. The dynamic linker has to then mprotect the executable segments with PROT_BTI. In case of static linked executables or in case of the dynamic linker itself, PROT_BTI protection is done by the operating system. On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check the properties of a binary because PT_NOTE can be unreliable with old linkers (old linkers just append the notes of input objects together and add them to the output without checking them for consistency which means multiple incompatible GNU property notes can be present in PT_NOTE). BTI property is handled in the loader even if glibc is not built with BTI support, so in theory user code can be BTI protected independently of glibc. In practice though user binaries are not marked with the BTI property if glibc has no support because the static linked libc objects (crt files, libc_nonshared.a) are unmarked. This patch relies on Linux userspace API that is not yet in a linux release but in v5.8-rc1 so scheduled to be in Linux 5.8. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* aarch64: new ifunc resolver ABISzabolcs Nagy2019-07-041-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing a second argument to the ifunc resolver allows accessing AT_HWCAP2 values from the resolver. AArch64 will start using AT_HWCAP2 on linux because for ilp32 to remain compatible with lp64 ABI no more than 32bit hwcap flags can be in AT_HWCAP which is already used up. Currently the relocation ordering logic does not guarantee that ifunc resolvers can call libc apis or access libc objects, so only the resolver arguments and runtime environment dependent instructions can be used to do the dispatch (this affects ifunc resolvers outside of the libc). Since ifunc resolver is target specific and only supposed to be called by the dynamic linker, the call ABI can be changed in a backward compatible way: Old call ABI passed hwcap as uint64_t, new abi sets the _IFUNC_ARG_HWCAP flag in the hwcap and passes a second argument that's a pointer to an extendible struct. A resolver has to check the _IFUNC_ARG_HWCAP flag before accessing the second argument. The new sys/ifunc.h installed header has the definitions for the new ABI, everything is in the implementation reserved namespace. An alternative approach is to try to support extern calls from ifunc resolvers such as getauxval, but that seems non-trivial https://sourceware.org/ml/libc-alpha/2017-01/msg00468.html * sysdeps/aarch64/Makefile: Install sys/ifunc.h and add tests. * sysdeps/aarch64/dl-irel.h (elf_ifunc_invoke): Update to new ABI. * sysdeps/aarch64/sys/ifunc.h: New file. * sysdeps/aarch64/tst-ifunc-arg-1.c: New file. * sysdeps/aarch64/tst-ifunc-arg-2.c: New file.
* Remove sysdeps/aarch64/soft-fp directory.Joseph Myers2018-05-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | As per <https://sourceware.org/ml/libc-alpha/2014-10/msg00369.html>, there should not be separate sysdeps/<arch>/soft-fp directories when those are used by all configurations that use sysdeps/<arch>, and, more generally, should not be sysdeps/foo/Implies files pointing to a subdirectory foo/bar. This patch eliminates the sysdeps/aarch64/soft-fp directory accordingly, merging its contents into sysdeps/aarch64. Tested with build-many-glibcs.py that installed stripped shared libraries for aarch64 configurations are unchanged by this patch. * sysdeps/aarch64/Implies: Remove aarch64/soft-fp. * sysdeps/aarch64/Makefile [$(subdir) = math] (CPPFLAGS): Add -I../soft-fp. Moved from .... * sysdeps/aarch64/soft-fp/Makefile: ... here. Remove file. * sysdeps/aarch64/soft-fp/e_sqrtl.c: Move to .... * sysdeps/aarch64/e_sqrtl.c: ... here. * sysdeps/aarch64/soft-fp/sfp-machine.h: Move to .... * sysdeps/aarch64/sfp-machine.h: ... here.
* Enable unwind info in libc-start.c and backtrace.cWilco Dijkstra2017-09-191-4/+0
| | | | | | | | | | | | | | | | | Add unwind info to __libc_start_main so that unwinding continues one extra level to _start. Similarly add unwind info to backtrace. Given many targets require this, do this in a general way. * csu/Makefile: Add -funwind-tables to libc-start.c. * debug/Makefile: Add -funwind-tables to backtrace.c. * sysdeps/aarch64/Makefile: Remove CFLAGS-backtrace.c. * sysdeps/arm/Makefile: Likewise. * sysdeps/i386/Makefile: Likewise. * sysdeps/m68k/Makefile: Likewise. * sysdeps/mips/Makefile: Likewise. * sysdeps/nios2/Makefile: Likewise. * sysdeps/sh/Makefile: Likewise. * sysdeps/sparc/Makefile: Likewise.
* [AArch64] Fix libc internal asm profiling codeSzabolcs Nagy2016-07-111-0/+4
| | | | | | | | | | | | | | | | | | | | | When glibc is built with --enable-profile, the ENTRY of asm functions includes CALL_MCOUNT for profiling. (matters for binaries static linked against libc_p.a.) CALL_MCOUNT did not save/restore argument registers around the _mcount call so it clobbered them. (it is enough to only save/restore the arguments passed to a given asm function, but that would be too many asm changes so it is simpler to always save all argument registers in this macro.) float args are not saved: mcount does not clobber the float regs and currently no asm function takes float arguments anyway. [BZ #18707] * sysdeps/aarch64/Makefile (CFLAGS-mcount.c): Add -mgeneral-regs-only. * sysdeps/aarch64/sysdep.h (CALL_MCOUNT): Save argument registers.
* Clean up sysdep-dl-routines variable.Roland McGrath2015-02-061-2/+0
|
* Relocate AArch64 from ports to libc.Marcus Shawcroft2014-02-111-0/+16
This patch moves the AArch64 port to the main sysdeps hierarchy. The move is essentially: git mv ports/sysdeps/aarch64 sysdeps/aarch64 git mv ports/sysdeps/unix/sysv/linux/aarch64 sysdeps/unix/sysv/linux/aarch64 The README is updated and I've updated ChangeLog.aarch64 along the lines of the ARM move. The AArch64 build has been tested to confirm that there were no changes in objdump -dr output or the shared objects.