RepoMirrors
/
musl
mirror of git://git.musl-libc.org/musl
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
musl/arch/arm/syscall_arch.h

108 lines
3.1 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
#define VDSO_USEFUL
#define VDSO_CGT_SYM "__vdso_clock_gettime"
#define VDSO_CGT_VER "LINUX_2.6"
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