riscv
/
musl
mirror of https://git.musl-libc.org/git/musl
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4385 Commits
2 Branches
78 Tags
7.6 MiB
Tree: d01fdc777d
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'd01fdc777d'
${ noResults }
musl/arch/arm/syscall_arch.h

110 lines
3.2 KiB
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.
14 years ago
#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.
8 years ago
#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).
14 years ago
#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.
8 years ago
#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).
14 years ago
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.
8 years ago
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).
14 years ago
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.
8 years ago
__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).
14 years ago
}
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.
8 years ago
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).
14 years ago
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.
8 years ago
__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).
14 years ago
}
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.
8 years ago
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).
14 years ago
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.
8 years ago
__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).
14 years ago
}
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.
8 years ago
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).
14 years ago
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.
8 years ago
__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).
14 years ago
}
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.
8 years ago
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).
14 years ago
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.
8 years ago
__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).
14 years ago
}
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.
14 years ago
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.
8 years ago
register long r7 __ASM____R7__ = n;
inline 5- and 6-argument syscalls on arm
12 years ago
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.
8 years ago
__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.
14 years ago
}
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.
8 years ago
register long r7 __ASM____R7__ = n;
inline 5- and 6-argument syscalls on arm
12 years ago
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.
8 years ago
__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.
14 years ago
}
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
11 years ago
#define VDSO_USEFUL
switch all existing 32-bit archs to 64-bit time_t this commit preserves ABI fully for existing interface boundaries between libc and libc consumers (applications or libraries), by retaining existing symbol names for the legacy 32-bit interfaces and redirecting sources compiled against the new headers to alternate symbol names. this does not necessarily, however, preserve the pairwise ABI of libc consumers with one another; where they use time_t-derived types in their interfaces with one another, it may be necessary to synchronize updates with each other. the intent is that ABI resulting from this commit already be stable and permanent, but it will not be officially so until a release is made. changes to some header-defined types that do not play any role in the ABI between libc and its consumers may still be subject to change. mechanically, the changes made by this commit for each 32-bit arch are as follows: - _REDIR_TIME64 is defined to activate the symbol redirections in public headers - COMPAT_SRC_DIRS is defined in arch.mak to activate build of ABI compat shims to serve as definitions for the original symbol names - time_t and suseconds_t definitions are changed to long long (64-bit) - IPC_STAT definition is changed to add the IPC_TIME64 bit (0x100), triggering conversion of semid_ds, shmid_ds, and msqid_ds split low/high time bits into new time_t members - structs semid_ds, shmid_ds, msqid_ds, and stat are modified to add new 64-bit time_t/timespec members at the end, maintaining existing layout of other members. - socket options (SO_*) and ioctl (sockios) command macros are redefined to use the kernel's "_NEW" values. in addition, on archs where vdso clock_gettime is used, the VDSO_CGT_SYM macro definition in syscall_arch.h is changed to use a new time64 vdso function if available, and a new VDSO_CGT32_SYM macro is added for use as fallback on kernels lacking time64.
7 years ago
#define VDSO_CGT32_SYM "__vdso_clock_gettime"
#define VDSO_CGT32_VER "LINUX_2.6"
#define VDSO_CGT_SYM "__vdso_clock_gettime64"
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
11 years ago
#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.
10 years ago
#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.
8 years ago
#define SYSCALL_IPC_BROKEN_MODE