summaryrefslogtreecommitdiff
path: root/arch/x32/bits
AgeCommit message (Collapse)AuthorLines
2015-03-18fix MINSIGSTKSZ values for archs with large signal contextsRich Felker-0/+5
the previous values (2k min and 8k default) were too small for some archs. aarch64 reserves 4k in the signal context for future extensions and requires about 4.5k total, and powerpc reportedly uses over 2k. the new minimums are chosen to fit the saved context and also allow a minimal signal handler to run. since the default (SIGSTKSZ) has always been 6k larger than the minimum, it is also increased to maintain the 6k usable by the signal handler. this happens to be able to store one pathname buffer and should be sufficient for calling any function in libc that doesn't involve conversion between floating point and decimal representations. x86 (both 32-bit and 64-bit variants) may also need a larger minimum (around 2.5k) in the future to support avx-512, but the values on these archs are left alone for now pending further analysis. the value for PTHREAD_STACK_MIN is not increased to match MINSIGSTKSZ at this time. this is so as not to preclude applications from using extremely small thread stacks when they know they will not be handling signals. unfortunately cancellation and multi-threaded set*id() use signals as an implementation detail and therefore require a stack large enough for a signal context, so applications which use extremely small thread stacks may still need to avoid using these features.
2015-03-12align x32 pthread type sizes to be common with 32-bit archsRich Felker-4/+4
previously, commit e7b9887e8b65253087ab0b209dc8dd85c9f09614 aligned the sizes with the glibc ABI. subsequent discussion during the merge of the aarch64 port reached a conclusion that we should reject larger arch-specific sizes, which have significant cost and no benefit, and stick with the existing common 32-bit sizes for all 32-bit/ILP32 archs and the x86_64 sizes for 64-bit archs. one peculiarity of this change is that x32 pthread_attr_t is now larger in musl than in the glibc x32 ABI, making it unsafe to call pthread_attr_init from x32 code that was compiled against glibc. with all the ABI issues of x32, it's not clear that ABI compatibility will ever work, but if it's needed, pthread_attr_init and related functions could be modified not to write to the last slot of the object. this is not a regression versus previous releases, since on previous releases the x32 pthread type sizes were all severely oversized already (due to incorrectly using the x86_64 LP64 definitions). moreover, x32 is still considered experimental and not ABI-stable.
2015-03-07fix FLT_ROUNDS to reflect the current rounding modeSzabolcs Nagy-1/+0
Implemented as a wrapper around fegetround introducing a new function to the ABI: __flt_rounds. (fegetround cannot be used directly from float.h)
2015-03-04fix POLLWRNORM and POLLWRBAND on mipsTrutz Behn-0/+0
these macros have the same distinct definition on blackfin, frv, m68k, mips, sparc and xtensa kernels. POLLMSG and POLLRDHUP additionally differ on sparc.
2015-03-04fix x32 pthread type definitionsRich Felker-7/+7
the previous definitions were copied from x86_64. not only did they fail to match the ABI sizes; they also wrongly encoded an assumption that long/pointer types are twice as large as int.
2015-03-03make all objects used with atomic operations volatileRich Felker-7/+7
the memory model we use internally for atomics permits plain loads of values which may be subject to concurrent modification without requiring that a special load function be used. since a compiler is free to make transformations that alter the number of loads or the way in which loads are performed, the compiler is theoretically free to break this usage. the most obvious concern is with atomic cas constructs: something of the form tmp=*p;a_cas(p,tmp,f(tmp)); could be transformed to a_cas(p,*p,f(*p)); where the latter is intended to show multiple loads of *p whose resulting values might fail to be equal; this would break the atomicity of the whole operation. but even more fundamental breakage is possible. with the changes being made now, objects that may be modified by atomics are modeled as volatile, and the atomic operations performed on them by other threads are modeled as asynchronous stores by hardware which happens to be acting on the request of another thread. such modeling of course does not itself address memory synchronization between cores/cpus, but that aspect was already handled. this all seems less than ideal, but it's the best we can do without mandating a C11 compiler and using the C11 model for atomics. in the case of pthread_once_t, the ABI type of the underlying object is not volatile-qualified. so we are assuming that accessing the object through a volatile-qualified lvalue via casts yields volatile access semantics. the language of the C standard is somewhat unclear on this matter, but this is an assumption the linux kernel also makes, and seems to be the correct interpretation of the standard.
2015-02-09add syscall numbers for the new execveat syscallSzabolcs Nagy-4/+7
this syscall allows fexecve to be implemented without /proc, it is new in linux v3.19, added in commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 (sh and microblaze do not have allocated syscall numbers yet) added a x32 fix as well: the io_setup and io_submit syscalls are no longer common with x86_64, so use the x32 specific numbers.
2015-02-01fix typo in x86_64/x32 user_fpregs_structFelix Janda-1/+1
mxcs_mask should be mxcr_mask
2015-01-30move MREMAP_MAYMOVE and MREMAP_FIXED out of bitsTrutz Behn-3/+0
the definitions are generic for all kernel archs. exposure of these macros now only occurs on the same feature test as for the function accepting them, which is believed to be more correct.
2014-12-23add new syscall numbers for bpf and kexec_file_loadSzabolcs Nagy-0/+4
these syscalls are new in linux v3.18, bpf is present on all supported archs except sh, kexec_file_load is only allocted for x86_64 and x32 yet. bpf was added in linux commit 99c55f7d47c0dc6fc64729f37bf435abf43f4c60 kexec_file_load syscall number was allocated in commit f0895685c7fd8c938c91a9d8a6f7c11f22df58d2
2014-12-21move wint_t definition to the shared part of alltypes.h.inRich Felker-1/+0
2014-10-08add new syscall numbers for seccomp, getrandom, memfd_createSzabolcs Nagy-0/+6
these syscalls are new in linux v3.17 and present on all supported archs except sh. seccomp was added in commit 48dc92b9fc3926844257316e75ba11eb5c742b2c it has operation, flags and pointer arguments (if flags==0 then it is the same as prctl(PR_SET_SECCOMP,...)), the uapi header for flag definitions is linux/seccomp.h getrandom was added in commit c6e9d6f38894798696f23c8084ca7edbf16ee895 it provides an entropy source when open("/dev/urandom",..) would fail, the uapi header for flags is linux/random.h memfd_create was added in commit 9183df25fe7b194563db3fec6dc3202a5855839c it allows anon mmap to have an fd, that can be shared, sealed and needs no mount point, the uapi header for flags is linux/memfd.h
2014-09-06add threads.h and needed per-arch types for mtx_t and cnd_tRich Felker-0/+2
based on patch by Jens Gustedt. mtx_t and cnd_t are defined in such a way that they are formally "compatible types" with pthread_mutex_t and pthread_cond_t, respectively, when accessed from a different translation unit. this makes it possible to implement the C11 functions using the pthread functions (which will dereference them with the pthread types) without having to use the same types, which would necessitate either namespace violations (exposing pthread type names in threads.h) or incompatible changes to the C++ name mangling ABI for the pthread types. for the rest of the types, things are much simpler; using identical types is possible without any namespace considerations.
2014-08-20add max_align_t definition for C11 and C++11Rich Felker-0/+2
unfortunately this needs to be able to vary by arch, because of a huge mess GCC made: the GCC definition, which became the ABI, depends on quirks in GCC's definition of __alignof__, which does not match the formal alignment of the type. GCC's __alignof__ unexpectedly exposes the an implementation detail, its "preferred alignment" for the type, rather than the formal/ABI alignment of the type, which it only actually uses in structures. on most archs the two values are the same, but on some (at least i386) the preferred alignment is greater than the ABI alignment. I considered using _Alignas(8) unconditionally, but on at least one arch (or1k), the alignment of max_align_t with GCC's definition is only 4 (even the "preferred alignment" for these types is only 4).
2014-08-17make pointers used in robust list volatileRich Felker-1/+1
when manipulating the robust list, the order of stores matters, because the code may be asynchronously interrupted by a fatal signal and the kernel will then access the robust list in what is essentially an async-signal context. previously, aliasing considerations made it seem unlikely that a compiler could reorder the stores, but proving that they could not be reordered incorrectly would have been extremely difficult. instead I've opted to make all the pointers used as part of the robust list, including those in the robust list head and in the individual mutexes, volatile. in addition, the format of the robust list has been changed to point back to the head at the end, rather than ending with a null pointer. this is to match the documented kernel robust list ABI. the null pointer, which was previously used, only worked because faults during access terminate the robust list processing.
2014-07-20add syscall numbers for the new renameat2 syscallSzabolcs Nagy-0/+2
it's like rename but with flags eg. to allow atomic exchange of two files, introduced in linux 3.15 commit 520c8b16505236fc82daa352e6c5e73cd9870cff
2014-05-30add sched_{get,set}attr syscall numbers and SCHED_DEADLINE macroSzabolcs Nagy-0/+6
linux 3.14 introduced sched_getattr and sched_setattr syscalls in commit d50dde5a10f305253cbc3855307f608f8a3c5f73 and the related SCHED_DEADLINE scheduling policy in commit aab03e05e8f7e26f51dee792beddcb5cca9215a5 but struct sched_attr "extended scheduling parameters data structure" is not yet exported to userspace (necessary for using the syscalls) so related uapi definitions are not added yet.
2014-04-15fix RLIMIT_ constants for mipsSzabolcs Nagy-0/+0
The mips arch is special in that it uses different RLIMIT_ numbers than other archs, so allow bits/resource.h to override the default RLIMIT_ numbers (empty on all archs except mips). Reported by orc.
2014-03-18fix signal.h breakage from moving stack_t to arch-specific bitsRich Felker-6/+6
in the previous changes, I missed the fact that both the prototype of the sigaltstack function and the definition of ucontext_t depend on stack_t.
2014-03-18move signal.h definition of stack_t to arch-specific bitsRich Felker-0/+6
it's different at least on mips. mips version will be fixed in a separate commit to show the change.
2014-03-17x32: fix struct statfsrofl0r-2/+4
the omission of the padding was uncovered by the latest regression statvfs regression test added to libc-test.
2014-03-11move struct semid_ds to from shared sys/sem.h to bitsRich Felker-0/+16
the definition was found to be incorrect at least for powerpc, and fixing this cleanly requires making the definition arch-specific. this will allow cleaning up the definition for other archs to make it more specific, and reversing some of the ugliness (time_t hacks) introduced with the x32 port. this first commit simply copies the existing definition to each arch without any changes. this is intentional, to make it easier to review changes made on a per-arch basis.
2014-02-23x32 port (diff against vanilla x86_64)rofl0r-662/+652
2014-02-23import vanilla x86_64 code as x32rofl0r-0/+1734