summaryrefslogtreecommitdiff
path: root/arch/aarch64
AgeCommit message (Collapse)AuthorFilesLines
2020-09-09aarch64: add new HWCAP2_ macros from linux v5.6Szabolcs Nagy1-0/+8
added in linux commit 1a50ec0b3b2e9a83f1b1245ea37a853aac2f741c arm64: Implement archrandom.h for ARMv8.5-RNG linux commit d4209d8b717311d114b5d47ba7f8249fd44e97c2 arm64: cpufeature: Export matrix and other features to userspace
2020-09-09aarch64: add HWCAP2_ macros from linux v5.3Szabolcs Nagy1-0/+2
these were missed before, added in linux commit 1201937491822b61641c1878ebcd16a93aed4540 arm64: Expose ARMv8.5 CondM capability to userspace linux commit ca9503fc9e9812aa6258e55d44edb03eb30fc46f arm64: Expose FRINT capabilities to userspace
2020-09-09add pidfd_getfd and openat2 syscall numbers from linux v5.6Szabolcs Nagy1-0/+2
also added clone3 on sh and m68k, on sh it's still missing (not yet wired up), but reserved so safe to add. see linux commit fddb5d430ad9fa91b49b1d34d0202ffe2fa0e179 open: introduce openat2(2) syscall linux commit 9a2cef09c801de54feecd912303ace5c27237f12 arch: wire up pidfd_getfd syscall linux commit 8649c322f75c96e7ced2fec201e123b2b073bf09 pid: Implement pidfd_getfd syscall linux commit e8bb2a2a1d51511e6b3f7e08125d52ec73c11139 m68k: Wire up clone3() syscall
2020-08-27deduplicate __pthread_self thread pointer adjustment out of each archRich Felker1-4/+4
the adjustment made is entirely a function of TLS_ABOVE_TP and TP_OFFSET. aside from avoiding repetition of the TP_OFFSET value and arithmetic, this change makes pthread_arch.h independent of the definition of struct __pthread from pthread_impl.h. this in turn will allow inclusion of pthread_arch.h to be moved to the top of pthread_impl.h so that it can influence the definition of the structure. previously, arch files were very inconsistent about the type used for the thread pointer. this change unifies the new __get_tp interface to always use uintptr_t, which is the most correct when performing arithmetic that may involve addresses outside the actual pointed-to object (due to TP_OFFSET).
2020-08-24deduplicate TP_ADJ logic out of each arch, replace with TP_OFFSETRich Felker1-1/+0
the only part of TP_ADJ that was not uniquely determined by TLS_ABOVE_TP was the 0x7000 adjustment used mainly on mips and powerpc variants.
2019-12-30add clone3 syscall number from linux v5.3Szabolcs Nagy1-0/+1
the syscall number is reserved on all targets, but it is not wired up on all targets, see linux commit 8f6ccf6159aed1f04c6d179f61f6fb2691261e84 Merge tag 'clone3-v5.3' of ... brauner/linux linux commit 8f3220a806545442f6f26195bc491520f5276e7c arch: wire-up clone3() syscall linux commit 7f192e3cd316ba58c88dfa26796cf77789dd9872 fork: add clone3
2019-12-30add pidfd_open syscall number from linux v5.3Szabolcs Nagy1-0/+1
see linux commit 7615d9e1780e26e0178c93c55b73309a5dc093d7 arch: wire-up pidfd_open() linux commit 32fcb426ec001cb6d5a4a195091a8486ea77e2df pid: add pidfd_open()
2019-11-02move time_t and suseconds_t definitions to common alltypes.h.inRich Felker1-3/+0
now that all 32-bit archs have 64-bit time_t (and suseconds_t), the arch-provided _Int64 macro (long or long long, as appropriate) can be used to define them, and arch-specific definitions are no longer needed.
2019-11-02move msghdr and cmsghdr out of bits/socket.hRich Felker1-31/+0
these structures can now be defined generically in terms of endianness and long size. previously, the 32-bit archs all shared a common definition from the generic bits header, and each 64-bit arch had to repeat the 64-bit version, with endian conditionals if the arch had variants of each endianness. I would prefer getting rid of the preprocessor conditionals for padding and instead using unnamed bitfield members, like commit 9b2921bea1d5017832e1b45d1fd64220047a9802 did for struct timespec. however, at present sendmsg, recvmsg, and recvmmsg need access to the padding members by name to zero them. this could perhaps be cleaned up in the future.
2019-10-17move pthread types out of per-arch alltypes.hRich Felker1-8/+0
policy has long been that these definitions are purely a function of whether long/pointer is 32- or 64-bit, and that they are not allowed to vary per-arch. move the definition to the shared alltypes.h.in fragment, using integer constant expressions in terms of sizeof to vary the array dimensions appropriately. I'm not sure whether this is more or less ugly than using preprocessor conditionals and two sets of definitions here, but either way is a lot less ugly than repeating the same thing for every arch.
2019-10-17define LONG_MAX via arch alltypes.h, strip down bits/limits.hRich Felker2-7/+2
LLONG_MAX is uniform for all archs we support and plenty of header and code level logic assumes it is, so it does not make sense for limits.h bits mechanism to pretend it's variable. LONG_BIT can be defined in terms of LONG_MAX; there's no reason to put it in bits. by moving LONG_MAX definition to __LONG_MAX in alltypes.h and moving LLONG_MAX out of bits, there are now no plain-C limits that are defined in the bits header, so the bits header only needs to be included in the POSIX or extended profiles. this allows the feature test macro logic to be removed from the bits header, facilitating a long-term goal of getting such logic out of bits. having __LONG_MAX in alltypes.h will allow further generalization of headers. archs without a constant PAGESIZE no longer need bits/limits.h at all.
2019-10-17remove use of endian.h from arch reloc.h headers, clean upRich Felker1-2/+0
building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea, __BYTE_ORDER is now available wherever alltypes.h is included. since reloc.h is only used from src/internal/dynlink.h, it can be assumed that __BYTE_ORDER is exposed. reloc.h is not permitted to be included in other contexts, and generally, like most arch headers, lacks inclusion guards that would allow such usage. the mips64 version mistakenly included such guards; they are removed for consistency.
2019-10-17remove indirect use of endian.h from public headersRich Felker1-2/+0
building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea, __BYTE_ORDER is now available wherever alltypes.h is included. endian.h should not be used since, in the future, it will expose identifiers that are not in the reserved namespace for the headers which were previously using it.
2019-10-17move __BYTE_ORDER definition to alltypes.hRich Felker2-5/+6
this change is motivated by the intersection of several factors. presently, despite being a nonstandard header, endian.h is exposing the unprefixed byte order macros and functions only if _BSD_SOURCE or _GNU_SOURCE is defined. this is to accommodate use of endian.h from other headers, including bits headers, which need to define structure layout in terms of endianness. with time64 switch-over, even more headers will need to do this. at the same time, the resolution of Austin Group issue 162 makes endian.h a standard header for POSIX-future, requiring that it expose the unprefixed macros and the functions even in standards-conforming profiles. changes to meet this new requirement would break existing internal usage of endian.h by causing it to violate namespace where it's used. instead, have the arch's alltypes.h define __BYTE_ORDER, either as a fixed constant or depending on the right arch-specific predefined macros for determining endianness. explicit literals 1234 and 4321 are used instead of __LITTLE_ENDIAN and __BIG_ENDIAN so that there's no danger of getting the wrong result if a macro is undefined and implicitly evaluates to 0 at the preprocessor level. the powerpc (32-bit) bits/endian.h being removed had logic for varying endianness, but our powerpc arch has never supported that and has always been big-endian-only. this logic is not carried over to the new __BYTE_ORDER definition in alltypes.h.
2019-10-17remove per-arch definitions for va_listRich Felker1-3/+0
now that commit f7f1079796abc6f97c69521d2334e9c7d3945dd8 removed the legacy i386 conditional definition, va_list is in no way arch-specific, and has no reason to be in the future. move it to the shared part of alltypes.h.in
2019-09-11aarch64: add HWCAP2 flags from linux v5.2Szabolcs Nagy1-0/+8
AT_HWCAP2 flags, see linux commit 671db581815faf17cbedd7fcbc48823a247d90b1 arm64: Expose DC CVADP to userspace linux commit 06a916feca2b262ab0c1a2aeb68882f4b1108a07 arm64: Expose SVE2 features for userspace
2019-09-11add new syscall numbers from linux v5.2Szabolcs Nagy1-0/+6
new mount api syscalls were added, same numers on all targets, see linux commit a07b20004793d8926f78d63eb5980559f7813404 vfs: syscall: Add open_tree(2) to reference or clone a mount linux commit 2db154b3ea8e14b04fee23e3fdfd5e9d17fbc6ae vfs: syscall: Add move_mount(2) to move mounts around linux commit 24dcb3d90a1f67fe08c68a004af37df059d74005 vfs: syscall: Add fsopen() to prepare for superblock creation linux commit ecdab150fddb42fe6a739335257949220033b782 vfs: syscall: Add fsconfig() for configuring and managing a context linux commit 93766fbd2696c2c4453dd8e1070977e9cd4e6b6d vfs: syscall: Add fsmount() to create a mount for a superblock linux commit cf3cba4a429be43e5527a3f78859b1bfd9ebc5fb vfs: syscall: Add fspick() to select a superblock for reconfiguration linux commit 9c8ad7a2ff0bfe58f019ec0abc1fb965114dde7d uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2] linux commit d8076bdb56af5e5918376cd1573a6b0007fc1a89 uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]
2019-07-30remove gratuitously-different arch-specific bits/ipc.h filesRich Felker1-12/+0
these differ from generic only in using endian-matched padding with a short __ipc_perm_seq field in place of the int field in generic. this is not a documented public interface anyway, and the original intent was to use int here. some ports just inadvertently slipped in the kernel short+padding form.
2019-07-30move IPC_64 from public bits/ipc.h to syscall_arch.hRich Felker2-2/+2
the definition of the IPC_64 macro controls the interface between libc and the kernel through syscalls; it's not a public API. the meaning is rather obscure. long ago, Linux's sysvipc *id_ds structures used 16-bit uids/gids and wrong types for a few other fields. this was in the libc5 era, before glibc. the IPC_64 flag (64 is a misnomer; it's more like 32) tells the kernel to use the modern[-ish] versions of the structures. the definition of IPC_64 has nothing to do with whether the arch is 32- or 64-bit. rather, due to either historical accident or intentional obnoxiousness, the kernel only accepts and masks off the 0x100 IPC_64 flag conditional on CONFIG_ARCH_WANT_IPC_PARSE_VERSION, i.e. for archs that want to provide, or that accidentally provided, both. for archs which don't define this option, no masking is performed and commands with the 0x100 bit set will fail as invalid. so ultimately, the definition is just a matter of matching an arbitrary switch defined per-arch in the kernel.
2019-07-29remove duplicates of new generic bits/msg.hRich Felker1-13/+0
2019-07-29remove duplicates of new generic bits/sem.hRich Felker1-14/+0
some of these were not exact duplicates, but had gratuitously different naming for padding, or omitted the endian checks because the arch is fixed-endian.
2019-07-29extricate bits/sem.h from x32 time_t hackRich Felker1-4/+4
various padding fields in the generic bits/sem.h were defined in terms of time_t as a cheap hack standing in for "kernel long", to allow x32 to use the generic version of the file. this was a really bad idea, as it ended up getting copied into lots of arch-specific versions of the bits file, and is a blocker to changing time_t to 64-bit on 32-bit archs. this commit adds an x32-specific version of the header, and changes padding type back from time_t to long (currently the same type on all archs but x32) in the generic header and all the others the hack got copied into.
2019-07-29remove duplicates of new generic bits/shm.hRich Felker1-24/+0
2019-07-18decouple struct stat from kernel typeRich Felker1-0/+21
presently, all archs/ABIs have struct stat matching the kernel stat[64] type, except mips/mipsn32/mips64 which do conversion hacks in syscall_arch.h to work around bugs in the kernel type. this patch completely decouples them and adds a translation step to the success path of fstatat. at present, this is just a gratuitous copying, but it opens up multiple possibilities for future support for 64-bit time_t on 32-bit archs and for cleaned-up/unified ABIs. for clarity, the mips hacks are not yet removed in this commit, so the mips kstat structs still correspond to the output of the hacks in their syscall_arch.h files, not the raw kernel type. a subsequent commit will fix this.
2019-07-01add new syscall numbers from linux v5.1Szabolcs Nagy1-0/+4
syscall numbers are now synced up across targets (starting from 403 the numbers are the same on all targets other than an arch specific offset) IPC syscalls sem*, shm*, msg* got added where they were missing (except for semop: only semtimedop got added), the new semctl, shmctl, msgctl imply IPC_64, see linux commit 0d6040d4681735dfc47565de288525de405a5c99 arch: add split IPC system calls where needed new 64bit time_t syscall variants got added on 32bit targets, see linux commit 48166e6ea47d23984f0b481ca199250e1ce0730a y2038: add 64-bit time_t syscalls to all 32-bit architectures new async io syscalls got added, see linux commit 2b188cc1bb857a9d4701ae59aa7768b5124e262e Add io_uring IO interface linux commit edafccee56ff31678a091ddb7219aba9b28bc3cb io_uring: add support for pre-mapped user IO buffers a new syscall got added that uses the fd of /proc/<pid> as a stable handle for processes: allows sending signals without pid reuse issues, intended to eventually replace rt_sigqueueinfo, kill, tgkill and rt_tgsigqueueinfo, see linux commit 3eb39f47934f9d5a3027fe00d906a45fe3a15fad signal: add pidfd_send_signal() syscall on some targets (arm, m68k, s390x, sh) some previously missing syscall numbers got added as well.
2019-04-17math: add fp_arch.h with fp_barrier and fp_force_evalSzabolcs Nagy1-0/+25
C99 has ways to support fenv access, but compilers don't implement it and assume nearest rounding mode and no fp status flag access. (gcc has -frounding-math and then it does not assume nearest rounding mode, but it still assumes the compiled code itself does not change the mode. Even if the C99 mechanism was implemented it is not ideal: it requires all code in the library to be compiled with FENV_ACCESS "on" to make it usable in non-nearest rounding mode, but that limits optimizations more than necessary.) The math functions should give reasonable results in all rounding modes (but the quality may be degraded in non-nearest rounding modes) and the fp status flag settings should follow the spec, so fenv side-effects are important and code transformations that break them should be prevented. Unfortunately compilers don't give any help with this, the best we can do is to add fp barriers to the code using volatile local variables (they create a stack frame and undesirable memory accesses to it) or inline asm (gcc specific, requires target specific fp reg constraints, often creates unnecessary reg moves and multiple barriers are needed to express that an operation has side-effects) or extern call (only useful in tail-call position to avoid stack-frame creation and does not work with lto). We assume that in a math function if an operation depends on the input and the output depends on it, then the operation will be evaluated at runtime when the function is called, producing all the expected fenv side-effects (this is not true in case of lto and in case the operation is evaluated with excess precision that is not rounded away). So fp barriers are needed (1) to prevent the move of an operation within a function (in case it may be moved from an unevaluated code path into an evaluated one or if it may be moved across a fenv access), (2) force the evaluation of an operation for its side-effect when it has no input dependency (may be constant folded) or (3) when its output is unused. I belive that fp_barrier and fp_force_eval can take care of these and they should not be needed in hot code paths.
2019-03-13aarch64: add HWCAP_ definitions from linux v5.0Szabolcs Nagy1-0/+3
HWCAP_SB - speculation barrier instruction available added in linux commit bd4fb6d270bc423a9a4098108784f7f9254c4e6d HWCAP_PACA, HWCAP_PACG - pointer authentication instructions available (address and generic) added in linux commit 7503197562567b57ec14feb3a9d5400ebc56812f
2019-03-13aarch64, or1k: add kexec_file_load syscall number from linux v5.0Szabolcs Nagy1-0/+1
added in linux commit 4e21565b7fd4d9045765f697887e74a704135fe2
2019-03-13aarch64: add HWCAP_SSBS from linux v4.20Szabolcs Nagy1-0/+1
for armv8.5 speculative store bypass PSTATE bit support, added in linux commit d71be2b6c0e19180b5f80a6d42039cc074a693a2
2019-03-13aarch64, or1k: define rseq syscall number following linux v4.19Szabolcs Nagy1-0/+1
added in linux commit db7a2d1809a5b6b08d138ff68837f805fc073351
2018-12-09add io_pgetevents and rseq syscall numbers from linux v4.18Szabolcs Nagy1-0/+1
io_pgetevents is new in linux commit 7a074e96dee62586c935c80cecd931431bfdd0be rseq is new in linux commit d7822b1e24f2df5df98c76f0e94a5416349ff759
2018-10-16make thread-pointer-loading asm non-volatileRich Felker1-1/+1
this will allow the compiler to cache and reuse the result, meaning we no longer have to take care not to load it more than once for the sake of archs where the load may be expensive. depends on commit 1c84c99913bf1cd47b866ed31e665848a0da84a2 for correctness, since otherwise the compiler could hoist loads during stage 3 of dynamic linking before the initial thread-pointer setup.
2018-06-19aarch64: add HWCAP_ flags from linux v4.17Szabolcs Nagy1-0/+4
hwcaps for armv8.4, new in linux commit 7206dc93a58fb76421c4411eefa3c003337bcb2d
2018-06-19aarch64: add HWCAP_ASIMDFHM from linux v4.16Szabolcs Nagy1-0/+1
armv8.4 fp mul instructions. added in commit 3b3b681097fae73b7f5dcdd42db6cfdf32943d4c
2018-06-02fix TLS layout of TLS variant I when there is a gap above TPSzabolcs Nagy2-3/+4
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-02-22aarch64: add sve_context struct and related defines from linux v4.15Szabolcs Nagy1-0/+39
signal context definitions for scalable vector extension new in commit d0b8cd3187889476144bd9b13bf36a932c3e7952
2018-02-22aarch64: update hwcap.h for linux v4.15Szabolcs Nagy1-0/+6
HWCAP_SVE is new in linux commit 43994d824e8443263dc98b151e6326bf677be52e HWCAP_SHA3, HWCAP_SM3, HWCAP_SM4, HWCAP_ASIMDDP and HWCAP_SHA512 are new in f5e035f8694c3bdddc66ea46ecda965ee6853718
2018-02-22aarch64: add HWCAP_DCPOP from linux v4.14Szabolcs Nagy1-0/+1
indicates ARMv8.2-DCPoP persistent memory support extension. new in linux commit 7aac405ebb3224037efd56b73d82d181111cdac3
2018-01-31aarch64: fix mismatched type of ucontext_t uc_link memberWilliam Pitcock1-1/+1
2017-11-05aarch64: add extra_context struct from linux v4.13Szabolcs Nagy1-0/+7
allows expanding the signal frame beyond the 4k reserved space. new in linux commit 33f082614c3443d937f50fe936f284f62bbb4a1b
2017-11-05aarch64: add new HWCAP_* flags from linux v4.12Szabolcs Nagy1-0/+3
hwcap bits for armv8.3 extensions, added in linux commits c8c3798d2369e4285da44b244638eafe446a8f8a cb567e79fa504575cb97fb2f866d2040ed1c92e7 c651aae5a7732287c1c9bc974ece4ed798780544
2017-11-05add statx syscall numbers from linux v4.11Szabolcs Nagy1-0/+1
statx was added in linux commit a528d35e8bfcc521d7cb70aaf03e1bd296c8493f (there is no libc wrapper yet and microblaze and sh misses the number).
2017-11-05update aarch64 hwcap.h for linux v4.11Szabolcs Nagy1-0/+2
new hwcap bits were added in kernel commits 77c97b4ee21290f5f083173d957843b615abbff2 f92f5ce01ee6a6a86cbfc4e3b0d18529c302b1ea
2017-09-06make syscall.h consistent with linuxSzabolcs Nagy1-2/+1
most of the found naming differences don't matter to musl, because internally it unifies the syscall names that vary across targets, but for external code the names should match the kernel uapi. aarch64: __NR_fstatat is called __NR_newfstatat in linux. __NR_or1k_atomic got mistakenly copied from or1k. arm: __NR_arm_sync_file_range is an alias for __NR_sync_file_range2 __NR_fadvise64_64 is called __NR_arm_fadvise64_64 in linux, the old non-arm name is kept too, it should not cause issues. (powerpc has similar nonstandard fadvise and it uses the normal name.) i386: __NR_madvise1 was removed from linux in commit 303395ac3bf3e2cb488435537d416bc840438fcb 2011-11-11 microblaze: __NR_fadvise, __NR_fstatat, __NR_pread, __NR_pwrite had different name in linux. mips: __NR_fadvise, __NR_fstatat, __NR_pread, __NR_pwrite, __NR_select had different name in linux. mipsn32: __NR_fstatat is called __NR_newfstatat in linux. or1k: __NR__llseek is called __NR_llseek in linux. the old name is kept too because that's the name musl uses internally. powerpc: __NR_{get,set}res{gid,uid}32 was never present in powerpc linux. __NR_timerfd was briefly defined in linux but then got renamed.
2017-08-29add a_clz_64 helper functionSzabolcs Nagy1-0/+7
counts leading zero bits of a 64bit int, undefined on zero input. (has nothing to do with atomics, added to atomic.h so target specific helper functions are together.) there is a logarithmic generic implementation and another in terms of a 32bit a_clz_32 on targets where that's available.
2016-12-29add pkey_{mprotect,alloc,free} syscalls from linux v4.9Szabolcs Nagy1-0/+3
see linux commit e8c24d3a23a469f1f40d4de24d872ca7023ced0a and linux Documentation/x86/protection-keys.txt
2016-10-20add bits/hwcap.h and include it in sys/auxv.hSzabolcs Nagy1-0/+11
aarch64, arm, mips, mips64, mipsn32, powerpc, powerpc64 and sh have cpu feature bits defined in linux for AT_HWCAP auxv entry, so expose those in sys/auxv.h it seems the mips hwcaps were never exposed to userspace neither by linux nor by glibc, but that's most likely an oversight.
2016-07-03make brace placement in public header typedef'd structs consistentRich Felker1-2/+1
commit befa5866ee30d09c0c96e88af2eabff5911342ea performed this change for struct definitions that did not also involve typedef, but omitted the latter.
2016-07-03make brace placement in public header struct definitions consistentRich Felker4-10/+5
placing the opening brace on the same line as the struct keyword/tag is the style I prefer and seems to be the prevailing practice in more recent additions. these changes were generated by the command: find include/ arch/*/bits -name '*.h' \ -exec sed -i '/^struct [^;{]*$/{N;s/\n/ /;}' {} + and subsequently checked by hand to ensure that the regex did not pick up any false positives.
2016-07-03use the generic ioctl.h for x86_64, x32 and aarch64Szabolcs Nagy1-213/+0
they were slightly different in musl, but should be the same: the linux uapi and glibc headers are not different.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-09 20:23:18 +0000