about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* use 64-bit semid_ds layout in the generic version of bits/sem.hRich Felker2019-07-291-2/+0
| | | | | | | | this layout is slightly less common than the old generic one, but only because x86_64 and x32 wrongly (according to comments in the kernel headers) copied the i386 padding. for future archs, and with 64-bit time_t on 32-bit archs, the new layout here will become the most common, and it makes sense to treat it as the generic.
* collapse out byte order conditions in bits/sem.h for fixed-endian archsRich Felker2019-07-294-20/+0
| | | | | having preprocessor conditionals on byte order in the bits headers for fixed-endian archs is confusing at best. remove them.
* duplicate generic bits/sem.h for each arch using it, in prep to changeRich Felker2019-07-297-0/+112
|
* extricate bits/sem.h from x32 time_t hackRich Felker2019-07-297-25/+36
| | | | | | | | | | | | | | various padding fields in the generic bits/sem.h were defined in terms of time_t as a cheap hack standing in for "kernel long", to allow x32 to use the generic version of the file. this was a really bad idea, as it ended up getting copied into lots of arch-specific versions of the bits file, and is a blocker to changing time_t to 64-bit on 32-bit archs. this commit adds an x32-specific version of the header, and changes padding type back from time_t to long (currently the same type on all archs but x32) in the generic header and all the others the hack got copied into.
* remove trailing newlines from various versions of bits/shm.hRich Felker2019-07-299-9/+0
|
* remove duplicates of new generic bits/shm.hRich Felker2019-07-295-123/+0
|
* use 64-bit shmid_ds layout in the generic version of bits/shm.hRich Felker2019-07-291-3/+0
| | | | | | | | | this layout is more common already than the old generic, and should become even more common in the future with new archs added and with 64-bit time_t on 32-bit archs. the duplicate arch-specific copies are not removed yet in this commit, so as to assist git tooling in copy/rename tracking.
* duplicate generic bits/shm.h for each arch using it, in prep to changeRich Felker2019-07-295-0/+140
| | | | | | | | | | | | | there are more archs sharing the generic 64-bit version of the struct, which is uniform and much more reasonable, than sharing the current "generic" one, and depending on how time64 sysvipc is done for 32-bit archs, even more may be sharing the "64-bit version" in the future. so, duplicate the current generic to all archs using it (arm, i386, m68k, microblaze, or1k) so that the generic can be changed freely. this is recorded as its own commit mainly as a hint to git tooling, to assist in copy/move tracking.
* timerfd: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-291-0/+42
| | | | | the changes here are semantically and structurally identical to those made to timer_settime and timer_gettime for time64 support.
* sched_rr_get_interval: don't assume time_t is 32-bit on 32-bit archsRich Felker2019-07-291-0/+14
| | | | | | | | | | as with clock_getres, the time64 syscall for this is not necessary or useful, this time since scheduling timeslices are not on the order 68 years. if there's a 32-bit syscall, use it and expand the result into timespec; otherwise there is only one syscall and it does the right thing to store to timespec directly. on 64-bit archs, there is no change to the code after preprocessing.
* clock_getres: don't assume time_t is 32-bit on 32-bit archsRich Felker2019-07-291-0/+14
| | | | | | | | | | the time64 syscall for this is not necessary or useful, since clock resolution is generally better than 68-year granularity. if there's a 32-bit syscall, use it and expand the result into timespec; otherwise there is only one syscall and it does the right thing to store to timespec directly. on 64-bit archs, there is no change to the code after preprocessing.
* timer_gettime: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-291-0/+16
| | | | | | | | | | | | the time64 syscall has to be used if time_t is 64-bit, since there's no way of knowing before making a syscall whether the result will fit in 32 bits, and the 32-bit syscalls do not report overflow as an error. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the result is now read from the kernel through long[4] array, then copied into the timespec, to remove the assumption that time_t is the same as long.
* remove x32 syscall timespec fixup hacksRich Felker2019-07-293-101/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | the x32 syscall interfaces treat timespec's tv_nsec member as 64-bit despite the API type being long and long being 32-bit in the ABI. this is no problem for syscalls that store timespecs to userspace as results, but caused uninitialized padding to be misinterpreted as the high bits in syscalls that take timespecs as input. since the beginning of the port, we've dealt with this situation with hacks in syscall_arch.h, and injected between __syscall_cp_c and __syscall_cp_asm, to special-case the syscall numbers that involve timespecs as inputs and copy them to a form suitable to pass to the kernel. commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47 set the stage for removal of these hacks by letting us treat the "normal" x32 syscalls dealing with timespec as if they're x32's "time64" syscalls, effectively making x32 ax "time64-only 32-bit arch" like riscv32 will be when it's added. since then, all users of syscalls that x32's syscall_arch.h had hacks for have been updated to use time64 syscalls, so the hacks can be removed. there are still at least a few other timespec-related syscalls broken on x32, which were overlooked when the x32 hacks were done or added later. these include at least recvmmsg, adjtimex/clock_adjtime, and timerfd_settime, and they will be fixed independently later on.
* utimensat: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-291-6/+31
| | | | | | | | | | | | | | | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if either of the requested times does not fit in 32 bits. care is taken to normalize the inputs to account for UTIME_NOW or UTIME_OMIT in tv_nsec, in which case tv_sec should be ignored. this is needed not only to avoid spurious time64 syscalls that might waste time failing with ENOSYS, but also to accurately decide whether fallback is possible. if the requested time cannot be represented, the function fails with ENOTSUP, defined in general as "The implementation does not support the requested feature or value". neither the time64 syscall, nor this error, can happen on current 32-bit archs where time_t is a 32-bit type, and both are statically unreachable. on 64-bit archs, there are only superficial changes to the SYS_futimesat fallback path, which has been modified to pass long[4] instead of struct timeval[2] to the kernel, making it suitable for use on 32-bit archs even once time_t is changed to 64-bit. for 32-bit archs, the call to SYS_utimensat has also been changed to copy the timespecs through an array of long[4] rather than passing the timespec[2] in-place.
* clock_settime: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-291-0/+17
| | | | | | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if the requested time does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. if the time64 syscall is needed because the requested time does not fit in 32 bits, we define this as an error ENOTSUP, for "The implementation does not support the requested feature or value". on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is moved through an intermediate copy to remove the assumption that time_t is a 32-bit type.
* timer_settime: add support for time64 syscall, decouple 32-bit time_tRich Felker2019-07-291-0/+25
| | | | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, if either component of the itimerspec does not fit in 32 bits, or if time_t is 64-bit and the caller requested the old value, in which case there's a possibility that the old value might not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is moved through an intermediate copy to remove the assumption that time_t is a 32-bit type.
* pselect, ppoll: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-282-4/+34
| | | | | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if the requested timeout length does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there are only superficial changes to the code after preprocessing. both before and after these changes, these functions copied their timeout arguments to avoid letting the kernel clobber the caller's copies. now, the copying also serves to change the type from userspace timespec to a pair of longs, which makes a difference only in the 32-bit fallback case, not on 64-bit.
* futex wait operations: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-282-3/+41
| | | | | | | | | | | | | | | | | | | | | thanks to the original factorization using the __timedwait function, there are no FUTEX_WAIT calls anywhere else, giving us a single point of change to make nearly all the timed thread primitives time64-ready. the one exception is the FUTEX_LOCK_PI command for PI mutex timedlock. I haven't tried to make these two points share code, since they have different fallbacks (no non-private fallback needed for PI since PI was added later) and FUTEX_LOCK_PI isn't a cancellation point (thus allowing the whole code path to inline into pthread_mutex_timedlock). as for other changes in this series, the time64 syscall is used only if it's the only one defined for the arch, or if the requested timeout does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there are only superficial changes to the code after preprocessing. on current 32-bit archs, the time is passed via an intermediate copy to remove the assumption that time_t is a 32-bit type.
* semtimedop: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-281-2/+24
| | | | | | | | | | | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if the requested timeout does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is passed via an intermediate copy to remove the assumption that time_t is a 32-bit type. to avoid duplicating SYS_ipc/SYS_semtimedop choice logic, the code for 32-bit archs "falls through" after updating the timeout argument ts to point to a [compound literal] array of longs. in preparation for "time64-only" 32-bit archs, an extra case is added for neither SYS_ipc nor the non-time64 SYS_semtimedop existing; the ENOSYS failure path here should never be reachable, and is added just in case a compiler can't see that it's not reachable, to avoid spurious static analysis complaints.
* sigtimedwait: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-281-4/+24
| | | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if the requested timeout length does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there are only superficial changes to the code after preprocessing. on current 32-bit archs, the timeout is passed via an intermediate copy to remove the assumption that time_t is a 32-bit type.
* mq_timedsend, mq_timedreceive: add time64, decouple 32-bit time_tRich Felker2019-07-282-0/+34
| | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if the requested absolute timeout does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the timeout is passed via an intermediate copy to remove the assumption that time_t is a 32-bit type.
* clock_nanosleep: add time64 syscall support, decouple 32-bit time_tRich Felker2019-07-281-0/+25
| | | | | | | | | | | time64 syscall is used only if it's the only one defined for the arch, or if the requested time does not fit in 32 bits. on current 32-bit archs where time_t is a 32-bit type, this makes it statically unreachable. on 64-bit archs, there is no change to the code after preprocessing. on current 32-bit archs, the time is moved through an intermediate copy to remove the assumption that time_t is a 32-bit type.
* implement settimeofday in terms of clock_settime, not old syscallRich Felker2019-07-271-1/+6
| | | | | | | | | this is yet another place where special handling of time syscalls can and should be avoided by implementing legacy functions in terms of their modern replacements. in theory a fallback to SYS_settimeofday could be added to clock_settime, but SYS_clock_settime has been available since Linux 2.6.0 or earlier, i.e. all the way back to the minimum supported version.
* internally, define plain syscalls, if missing, as their time64 variantsRich Felker2019-07-271-0/+83
| | | | | | | | | | | | | this commit has no effect whatsoever right now, but is in preparation for a future riscv32 port and other future 32-bit archs that will be "time64-only" from the start on the kernel side. together with the previous x32 changes, this commit ensures that syscall call points that don't care about time (passing null timeouts, etc.) can continue to do so without having to special-case time64-only archs, and allows code using the time64 syscalls to uniformly test for the need to fallback with SYS_foo != SYS_foo_time64, rather than needing to check defined(SYS_foo) && SYS_foo != SYS_foo_time64.
* internally, define time64 syscalls on x32 as the existing syscallsRich Felker2019-07-271-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | x32 is odd in that it's the only ILP32 arch/ABI we have where time_t is 64-bit rather than (32-bit) long, and this has always been problematic in that it results in struct timespec having unused padding space, since tv_nsec has type long, which the kernel insists be zero- or sign-extended (due to negative tv_nsec being invalid, it doesn't matter which) to match the x86_64 type. up til now, we've had really ugly hacks in x32/syscall_arch.h to patch up the timespecs passed to the kernel. but the same requirement to zero- or sign-extend tv_nsec also applies to all the new time64 syscalls on true 32-bit archs. so let's take advantage of this to clean things up. this patch defines all of the time64 syscalls for x32 as aliases for the existing syscalls by the same name. this establishes the following invariants: - if the time64 form is defined, it takes time arguments as 64-bit objects, and tv_nsec inputs must be zero-/sign-extended to 64-bit. - if the time64 form is not defined, or if the time64 form is defined and is not equal to the "plain" form, the plain form takes time arguments as longs. this will avoid the need for protocols for archs to define appropriate types for each family of syscalls, and for the reader of the code to have to be aware of such type definitions. in some sense it might be simpler if the plain syscall form were undefined for x32, so that it would always take longs if defined. however, a number of these syscalls are used in contexts with a null time argument, or (e.g. futex) for commands that don't involve time at all, and having to introduce time64-specific logic to all those call points does not make sense. thus, while the "plain" forms are kept now just because they're needed until the affected code is converted over, they'll also almost surely be kept in the future as well.
* don't use futimesat syscall as utimensat fallback on x32Rich Felker2019-07-271-0/+2
| | | | | | | | | | kernel support for x32 was added long after the utimensat syscall was already available, so having a fallback is just wasted code size. also, for changes related to time64 support on 32-bit archs, I want to be able to assume the old futimesat syscall always works with longs, which is true except for x32. by ensuring that it's not used on x32, the needed invariant is established.
* fix and simplify futimesat fallback in utimensatRich Felker2019-07-271-6/+4
| | | | | | | | | | | | previously the fallback wrongly failed with EINVAL rather than ENOSYS when UTIME_NOW was used with one component but not both. commit dd5f50da6f6c3df5647e922e47f8568a8896a752 introduced this behavior when initially adding the fallback support. instead, detect the case where both are UTIME_NOW early and replace with a null times pointer; this may improve performance slightly (less copy from user), and removes the complex logic from the fallback case. it also makes things slightly simpler for adding time64 code paths.
* refactor thrd_sleep and nanosleep in terms of clock_nanosleepRich Felker2019-07-274-5/+11
| | | | | | | | | | | for namespace-safety with thrd_sleep, this requires an alias, which is also added. this eliminates all but one direct call point for nanosleep syscalls, and arranges that 64-bit time_t conversion logic will only need to exist in one file rather than three. as a bonus, clock_nanosleep with CLOCK_REALTIME and empty flags is now implemented as SYS_nanosleep, thereby working on older kernels that may lack POSIX clocks functionality.
* use the correct stat structure in the fstat pathSamuel Holland2019-07-211-4/+4
| | | | | | | | | | | | commit 01ae3fc6d48f4a45535189b7a6db286535af08ca modified fstatat to translate the kernel's struct stat ("kstat") into the libc struct stat. To do this, it created a local kstat object, and copied its contents into the user-provided object. However, the commit neglected to update the fstat compatibility path and its fallbacks. They continued to pass the user-supplied object to the kernel, later overwiting it with the uninitialized memory in the local temporary.
* refactor adjtime function using adjtimex function instead of syscallRich Felker2019-07-201-1/+1
| | | | | this removes the assumption that userspace struct timex matches the syscall type and sets the stage for 64-bit time_t on 32-bit archs.
* refactor adjtimex in terms of clock_adjtimeRich Felker2019-07-202-2/+4
| | | | | | this sets the stage for having the conversion logic for 64-bit time_t all in one file, and as a bonus makes clock_adjtime for CLOCK_REALTIME work even on kernels too old to have the clock_adjtime syscall.
* fix inadvertent introduction of extern object stxRich Felker2019-07-191-1/+1
| | | | | commit dfc81828f7ab41da08f744c44117a1bb20a05749 accidentally defined an instance of struct statx along with the struct declaration.
* implement fstatat with SYS_statx, conditional on undersized kstat timeRich Felker2019-07-181-2/+68
| | | | | | | | | | | | | | this commit adds a new backend for fstatat (and thereby the whole stat family) using the SYS_statx syscall, but conditions the new code on the kernel stat structure's time fields being smaller than time_t. in principle that should make it all dead code at present, but mips64 has a broken stat structure with 32-bit time fields despite having 64-bit time_t elsewhere, so on mips64 it is a functional change that makes post-Y2038 filesystem timestamps accessible. whenever the 32-bit archs end up getting 64-bit time_t, regardless of how that happens, the changes in this commit will automatically take effect for them too.
* cleanup includes now that stat, lstat no longer make direct syscallsRich Felker2019-07-182-2/+0
|
* restore property that fstat(AT_FDCWD) fails with EBADFRich Felker2019-07-181-0/+1
| | | | | | AT_FDCWD is not a valid file descriptor, so POSIX requires fstat to fail with EBADF. if passed to fstatat, the call would spuriously succeed and return results for the working directory.
* remove mips/n32/64 stat struct hacks from syscall machineryRich Felker2019-07-186-213/+36
| | | | | | now that we have a kstat structure decoupled from the public struct stat, we can just use the broken kernel structures directly and let the code in fstatat do the translation.
* decouple struct stat from kernel typeRich Felker2019-07-1817-4/+364
| | | | | | | | | | | | | | | presently, all archs/ABIs have struct stat matching the kernel stat[64] type, except mips/mipsn32/mips64 which do conversion hacks in syscall_arch.h to work around bugs in the kernel type. this patch completely decouples them and adds a translation step to the success path of fstatat. at present, this is just a gratuitous copying, but it opens up multiple possibilities for future support for 64-bit time_t on 32-bit archs and for cleaned-up/unified ABIs. for clarity, the mips hacks are not yet removed in this commit, so the mips kstat structs still correspond to the output of the hacks in their syscall_arch.h files, not the raw kernel type. a subsequent commit will fix this.
* refactor all stat functions in terms of fstatatRich Felker2019-07-184-23/+37
| | | | | | | | | equivalent logic for fstat+O_PATH fallback and direct use of stat/lstat syscalls where appropriate is kept, now in the fstatat function. this change both improves functionality (now, fstatat forms equivalent to fstat/lstat/stat will work even on kernels too old to have the at functions) and localizes direct interfacing with the kernel stat structure to one file.
* remove utterly wrong includes from mips64/n32 bits/stat.hRich Felker2019-07-182-6/+0
| | | | | | | | these were overlooked during review. bits headers are not allowed to pull in additional headers (note: that rule is currently broken in other places but just for endian.h). string.h has no place here anyway, and including bits/alltypes.h without defining macros to request types from it is a nop.
* use register constraint instead of memory operand for riscv64 atomicsRich Felker2019-07-171-8/+8
| | | | | | | | the "A" constraint is simply for an address expression that's a single register, but it's not yet supported by clang, and has no advantage here over just using a register operand for the address. the latter is actually preferable in the a_cas_p case because it avoids aliasing an lvalue onto the memory.
* fix riscv64 atomic asm constraintsRich Felker2019-07-171-6/+10
| | | | | | | most egregious problem was the lack of memory clobber and lack of volatile asm; this made the atomics memory barriers but not compiler barriers. use of "+r" rather than "=r" for a clobbered temp was also wrong, since the initial value is indeterminate.
* fix riscv64 syscall asm constraintRich Felker2019-07-171-1/+1
| | | | | | | having "+r"(a0) is redundant with "0"(a0) in syscalls with at least 1 arg, which is arguably a constraint violation (clang treats it as such), and an invalid input with indeterminate value in the 0-arg case. use the "=r"(a0) form instead.
* fix broken lseek on x32 (x86_64/ILP32) with offsets larger than LONG_MAXRich Felker2019-07-161-0/+15
| | | | | this is analogous to commit 918c5fa0fc656e49b1ab9ce47183a23e3a36bc00 which fixed the corresponding issue for mips n32.
* fix broken lseek on mipsn32 with offsets larger than LONG_MAXRich Felker2019-07-161-0/+20
| | | | | | | | | | | | | | | mips n32 has 32-bit long, and generally uses long syscall arguments and return values, but provides only SYS_lseek, not SYS_llseek. we have some framework (syscall_arg_t, added for x32) to make syscall arguments 64-bit in such a setting, but it's not clear whether this could match the sign-extension semantics needed for 32-bit args to all the other syscalls, and we don't have any existing mechanism to allow the return value of syscalls to be something other than long. instead, just provide a custom mipsn32 version of the lseek function doing its own syscall asm with 64-bit arguments. as a result of commit 03919b26ed41c31876db41f7cee076ced4513fad, stdio will also get the new code, fixing fseeko/ftello too.
* clean up mips64/n32 syscall asm constraintsRich Felker2019-07-162-54/+56
| | | | | | | | | | | | | | | | | ever since inline syscalls were added for (o32) mips in commit 328810d32524e4928fec50b57e37e1bf330b2e40, the asm has nonsensically loaded the syscall number, rather than taking $2 as an input constraint to let the compiler load it. commit cfc09b1ecf0c6981494fd73dffe234416f66af10 improved on this somewhat by allowing a constant syscall number to propagate into an immediate, but missed that the whole operation made no sense. now, only $4, $5, $6, $8, and $9 are potential input-only registers. $2 is always input and output, and $7 is both when it's an argument, otherwise output-only. previously, $7 was treated as an input (with a "1" constraint matching its output position) even when it was not an input, which was arguably undefined behavior (asm input from indeterminate value). this is corrected.
* deduplicate mips64/n32 syscall clobbered register listsRich Felker2019-07-162-28/+22
| | | | | | | | | | | | | | this patch is not purely non-functional changes, since before, $8 and $9 were wrongly in the clobberlist for syscalls with fewer than 5 or 6 arguments. of course it's impossible for syscalls to have different clobbers depending on their number of arguments. the clobberlist for the recently-added 5- and 6-argument forms was correct, and for the 0- to 4-argument forms was erroneously copied from the mips o32 ABI where the additional arguments had to be passed on the stack. in making this change, I reviewed the kernel sources, and $8 and $9 are always saved for 64-bit kernels since they're part of the syscall argument list for n32 and n64 ABIs.
* use namespace-safe __lseek for __stdio_seek instead of direct syscallRich Felker2019-07-163-10/+6
| | | | | | this probably saves a few bytes, avoids duplicating the clunky lseek/_llseek syscall convention in two places, and sets the stage for fixing broken seeks on x32 and mipsn32.
* release 1.1.23 v1.1.23Rich Felker2019-07-162-1/+39
|
* update year in COPYRIGHT fileRich Felker2019-07-151-1/+1
|
* update authors/contributors listRich Felker2019-07-151-0/+15
| | | | | | | | | these additions were made by scanning git log since the last major update in commit 1366b3c5e6d89d5ba90dd41fe5bf0246c5299b84. as before my aim was adding everyone with either substantial code contributions or a pattern of ongoing simple patch submission; any omissions are unintentional.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-09 06:51:04 +0000