Commit Graph

11 Commits

Author SHA1 Message Date
Szabolcs Nagy
c076a0bc69 malloc: Only support zeroing and not arbitrary memset with mtag
The memset api is suboptimal and does not provide much benefit. Memory
tagging only needs a zeroing memset (and only for memory that's sized
and aligned to multiples of the tag granule), so change the internal
api and the target hooks accordingly.  This is to simplify the
implementation of the target hook.

Reviewed-by: DJ Delorie <dj@redhat.com>
2021-03-26 11:03:06 +00:00
Richard Earnshaw
d27f0e5d88 aarch64: Add aarch64-specific files for memory tagging support
This final patch provides the architecture-specific implementation of
the memory-tagging support hooks for aarch64.
2020-12-21 15:25:25 +00:00
Szabolcs Nagy
e156dabc76 aarch64: Add variant PCS lazy binding test [BZ #26798]
This test fails without bug 26798 fixed because some integer registers
likely get clobbered by lazy binding and variant PCS only allows x16
and x17 to be clobbered at call time.

The test requires binutils 2.32.1 or newer for handling variant PCS
symbols. SVE registers are not covered by this test, to avoid the
complexity of handling multiple compile- and runtime feature support
cases.
2020-11-02 09:39:24 +00:00
Szabolcs Nagy
de9301c02e aarch64: ensure objects are BTI compatible
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>
2020-07-08 15:02:38 +01:00
Sudakshina Das
605338745b aarch64: enable BTI at runtime
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>
2020-07-08 15:02:37 +01:00
Szabolcs Nagy
2b8a3c86e7 aarch64: new ifunc resolver ABI
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.
2019-07-04 11:13:32 +01:00
Joseph Myers
8f145c7712 Remove sysdeps/aarch64/soft-fp directory.
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.
2018-05-22 17:23:34 +00:00
Wilco Dijkstra
ca3a382ea3 Enable unwind info in libc-start.c and backtrace.c
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.
2017-09-19 15:07:58 +01:00
Szabolcs Nagy
efbe665c3a [AArch64] Fix libc internal asm profiling code
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.
2016-07-11 09:50:41 +01:00
Roland McGrath
ac9e0e5e40 Clean up sysdep-dl-routines variable. 2015-02-06 10:42:08 -08:00
Marcus Shawcroft
75eff3fe90 Relocate AArch64 from ports to libc.
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.
2014-02-11 11:36:00 +00:00