RepoMirrors/musl
1
0
Fork 0
mirror of git://git.musl-libc.org/musl synced 2025-01-24 07:33:15 +00:00
Code Issues Packages Projects Releases Wiki Activity
2c124e13bd
musl/arch/arm/syscall_arch.h

111 lines
3.2 KiB
C
Raw Normal View History

syscall organization overhaul now public syscall.h only exposes __NR_* and SYS_* constants and the variadic syscall function. no macros or inline functions, no __syscall_ret or other internal details, no 16-/32-bit legacy syscall renaming, etc. this logic has all been moved to src/internal/syscall.h with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the amount of arch-specific stuff has been reduced to a minimum. changes still need to be reviewed/double-checked. minimal testing on i386 and mips has already been performed.
2012-09-09 02:43:14 +00:00
#define __SYSCALL_LL_E(x) \
((union { long long ll; long l[2]; }){ .ll = x }).l[0], \
((union { long long ll; long l[2]; }){ .ll = x }).l[1]
#define __SYSCALL_LL_O(x) 0, __SYSCALL_LL_E((x))
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
#ifdef __thumb__
/* Avoid use of r7 in asm constraints when producing thumb code,
* since it's reserved as frame pointer and might not be supported. */
#define __ASM____R7__
#define __asm_syscall(...) do { \
__asm__ __volatile__ ( "mov %1,r7 ; mov r7,%2 ; svc 0 ; mov r7,%1" \
: "=r"(r0), "=&r"((int){0}) : __VA_ARGS__ : "memory"); \
return r0; \
} while (0)
#else
#define __ASM____R7__ __asm__("r7")
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
#define __asm_syscall(...) do { \
__asm__ __volatile__ ( "svc 0" \
: "=r"(r0) : __VA_ARGS__ : "memory"); \
return r0; \
} while (0)
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
#endif
/* For thumb2, we can allow 8-bit immediate syscall numbers, saving a
* register in the above dance around r7. Does not work for thumb1 where
* only movs, not mov, supports immediates, and we can't use movs because
* it doesn't support high regs. */
#ifdef __thumb2__
#define R7_OPERAND "rI"(r7)
#else
#define R7_OPERAND "r"(r7)
#endif
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
static inline long __syscall0(long n)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
register long r0 __asm__("r0");
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND);
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
}
static inline long __syscall1(long n, long a)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
register long r0 __asm__("r0") = a;
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND, "0"(r0));
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
}
static inline long __syscall2(long n, long a, long b)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
register long r0 __asm__("r0") = a;
register long r1 __asm__("r1") = b;
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND, "0"(r0), "r"(r1));
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
}
static inline long __syscall3(long n, long a, long b, long c)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
register long r0 __asm__("r0") = a;
register long r1 __asm__("r1") = b;
register long r2 __asm__("r2") = c;
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND, "0"(r0), "r"(r1), "r"(r2));
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
}
static inline long __syscall4(long n, long a, long b, long c, long d)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
register long r0 __asm__("r0") = a;
register long r1 __asm__("r1") = b;
register long r2 __asm__("r2") = c;
register long r3 __asm__("r3") = d;
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND, "0"(r0), "r"(r1), "r"(r2), "r"(r3));
inline syscall support for arm most pure-syscall-wrapper functions compile to the smallest/simplest code possible (save r7 ; load syscall # ; svc 0 ; restore r7 ; tail call to __syscall_ret).
2012-09-09 05:29:19 +00:00
}
syscall organization overhaul now public syscall.h only exposes __NR_* and SYS_* constants and the variadic syscall function. no macros or inline functions, no __syscall_ret or other internal details, no 16-/32-bit legacy syscall renaming, etc. this logic has all been moved to src/internal/syscall.h with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the amount of arch-specific stuff has been reduced to a minimum. changes still need to be reviewed/double-checked. minimal testing on i386 and mips has already been performed.
2012-09-09 02:43:14 +00:00
static inline long __syscall5(long n, long a, long b, long c, long d, long e)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline 5- and 6-argument syscalls on arm
2014-11-23 02:06:40 +00:00
register long r0 __asm__("r0") = a;
register long r1 __asm__("r1") = b;
register long r2 __asm__("r2") = c;
register long r3 __asm__("r3") = d;
register long r4 __asm__("r4") = e;
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND, "0"(r0), "r"(r1), "r"(r2), "r"(r3), "r"(r4));
syscall organization overhaul now public syscall.h only exposes __NR_* and SYS_* constants and the variadic syscall function. no macros or inline functions, no __syscall_ret or other internal details, no 16-/32-bit legacy syscall renaming, etc. this logic has all been moved to src/internal/syscall.h with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the amount of arch-specific stuff has been reduced to a minimum. changes still need to be reviewed/double-checked. minimal testing on i386 and mips has already been performed.
2012-09-09 02:43:14 +00:00
}
static inline long __syscall6(long n, long a, long b, long c, long d, long e, long f)
{
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
register long r7 __ASM____R7__ = n;
inline 5- and 6-argument syscalls on arm
2014-11-23 02:06:40 +00:00
register long r0 __asm__("r0") = a;
register long r1 __asm__("r1") = b;
register long r2 __asm__("r2") = c;
register long r3 __asm__("r3") = d;
register long r4 __asm__("r4") = e;
register long r5 __asm__("r5") = f;
work around arm gcc's rejection of r7 asm constraints in thumb mode in thumb mode, r7 is the ABI frame pointer register, and unless frame pointer is disabled, gcc insists on treating it as a fixed register, refusing to spill it to satisfy constraints. unfortunately, r7 is also used in the syscall ABI for passing the syscall number. up til now we just treated this as a requirement to disable frame pointer when generating code as thumb, but it turns out gcc forcibly enables frame pointer, and the fixed register constraint that goes with it, for functions which contain VLAs. this produces an unacceptable arch-specific constraint that (non-arm-specific) source files making syscalls cannot use VLAs. as a workaround, avoid r7 register constraints when producing thumb code and instead save/restore r7 in a temp register as part of the asm block. at some point we may want/need to support armv6-m/thumb1, so the asm has been tweaked to be thumb1-compatible while also near-optimal for thumb2: it allows the temp and/or syscall number to be in high registers (necessary since r0-r5 may all be used for syscalll args) and in thumb2 mode allows the syscall number to be an 8-bit immediate.
2018-05-01 18:34:22 +00:00
__asm_syscall(R7_OPERAND, "0"(r0), "r"(r1), "r"(r2), "r"(r3), "r"(r4), "r"(r5));
syscall organization overhaul now public syscall.h only exposes __NR_* and SYS_* constants and the variadic syscall function. no macros or inline functions, no __syscall_ret or other internal details, no 16-/32-bit legacy syscall renaming, etc. this logic has all been moved to src/internal/syscall.h with the arch-specific parts in arch/$(ARCH)/syscall_arch.h, and the amount of arch-specific stuff has been reduced to a minimum. changes still need to be reviewed/double-checked. minimal testing on i386 and mips has already been performed.
2012-09-09 02:43:14 +00:00
}
arm: add vdso support vdso will be available on arm in linux v4.2, the user-space code for it is in kernel commit 8512287a8165592466cb9cb347ba94892e9c56a5
2015-06-03 09:32:14 +00:00
fix posix_fadvise syscall args on powerpc, unify with arm fix commit 6d38c9cf80f47623e5e48190046673bbd0dc410b provided an arm-specific version of posix_fadvise to address the alternate argument order the kernel expects on arm, but neglected to address that powerpc (32-bit) has the same issue. instead of having arch variant files in duplicate, simply put the alternate version in the top-level file under the control of a macro defined in syscall_arch.h.
2016-07-01 17:32:35 +00:00
#define SYSCALL_FADVISE_6_ARG
work around broken kernel struct ipc_perm on some big endian archs the mode member of struct ipc_perm is specified by POSIX to have type mode_t, which is uniformly defined as unsigned int. however, Linux defines it with type __kernel_mode_t, and defines __kernel_mode_t as unsigned short on some archs. since there is a subsequent padding field, treating it as a 32-bit unsigned int works on little endian archs, but the order is backwards on big endian archs with the erroneous definition. since multiple archs are affected, remedy the situation with fixup code in the affected functions (shmctl, semctl, and msgctl) rather than repeating the same shims in syscall_arch.h for every affected arch.
2018-06-20 04:07:09 +00:00
#define SYSCALL_IPC_BROKEN_MODE
re-enable vdso clock_gettime on arm (32-bit) with workaround commit 4486c579cbf0d989080705f515d08cb48636ba88 disabled vdso clock_gettime on arm due to a Linux kernel bug that was not understood at the time, whereby the vdso function silently produced catastrophically wrong results on some systems. since then, the bug was tracked down to the way the arm kernel disabled use of vdso clock_gettime on kernels where the necessary timer was not available or was disabled. it simply patched out the symbols, but it only did this for the legacy time32 functions, and left the time64 function in place but non-operational. kernel commit 4405bdf3c57ec28d606bdf5325f1167505bfdcd4 (first present in 5.8) provided the fix. if this were a bug that impacted all users of the broken kernel versions, we could probably ignore it and assume it had been patched or replaced. however, it's very possible that these kernels appear in the wild in devices running time32 userspace (glibc, musl 1.1.x, or some other environment) where they appear to work fine, but where our new binaries would fail catastrophically if we used the time64 vdso function. since the kernel has not (yet?) given us a way to probe for the working time64 vdso function semantically, we work around the problem by refusing to use the time64 one unless the time32 one is also present. this will revert to not using vdso at all if the time32 one is ever removed, but at least that's safe against wrong results and is just a missed optimization.
2022-09-12 12:38:03 +00:00
#define VDSO_USEFUL
#define VDSO_CGT32_SYM "__vdso_clock_gettime"
#define VDSO_CGT32_VER "LINUX_2.6"
#define VDSO_CGT_SYM "__vdso_clock_gettime64"
#define VDSO_CGT_VER "LINUX_2.6"
#define VDSO_CGT_WORKAROUND 1
Reference in New Issue Copy Permalink