summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-09-11fix arm __tlsdesc_dynamic when built as thumb code without __ARM_ARCH>=5Rich Felker1-0/+4
we don't actually support building asm source files as thumb1, but it's possible that the condition __ARM_ARCH>=5 would be false on old compilers that did not define __ARM_ARCH at all. avoiding that would require enumerating all of the possible __ARM_ARCH_*__ macros for testing. as noted in commit 05870abeaac0588fb9115cfd11f96880a0af2108, mov lr,pc is not valid for saving a return address when in thumb mode. since this code is a hot path (dynamic TLS access), don't do the out-of-line bl->bx chaining to save the return value; instead, use the fact that this file is preprocessed asm to add the missing thumb bit with an add in place of the mov. the change here does not affect builds for ISA levels new enough to have a thread pointer read instruction, or for armv5 and later as long as the compiler properly defines __ARM_ARCH, or for any build as arm (not thumb) code. it's likely that it makes no difference whatsoever to any present-day practical build environments, but nonetheless now it's safe. as an alternative, we could just assume __thumb__ implies availability of blx since we don't support building asm source files as thumb1. I didn't do that in order to avoid having a wrong assumption here if that ever changes.
2019-09-11fix arm __a_barrier_oldkuser when built as thumbRich Felker1-2/+2
as noted in commit 05870abeaac0588fb9115cfd11f96880a0af2108, mov lr,pc is not a valid method for saving the return address in code that might be built as thumb. this one is unlikely to matter, since any ISA level that has thumb2 should also have native implementations of atomics that don't involve kuser_helper, and the affected code is only used on very old kernels to begin with.
2019-09-11fix code path where child function returns in arm __clone built as thumbRich Felker1-7/+3
mov lr,pc is not a valid way to save the return address in thumb mode since it omits the thumb bit. use a chain of bl and bx to emulate blx. this could be avoided by converting to a .S file with preprocessor conditions to use blx if available, but the time cost here is dominated by the syscall anyway. while making this change, also remove the remnants of support for pre-bx ISA levels. commit 9f290a49bf9ee247d540d3c83875288a7991699c removed the hack from the parent code paths, but left the unnecessary code in the child. keeping it would require rewriting two code paths rather than one, and is useless for reasons described in that commit.
2019-09-11aarch64: add HWCAP2 flags from linux v5.2Szabolcs Nagy1-0/+8
AT_HWCAP2 flags, see linux commit 671db581815faf17cbedd7fcbc48823a247d90b1 arm64: Expose DC CVADP to userspace linux commit 06a916feca2b262ab0c1a2aeb68882f4b1108a07 arm64: Expose SVE2 features for userspace
2019-09-11add new syscall numbers from linux v5.2Szabolcs Nagy16-0/+97
new mount api syscalls were added, same numers on all targets, see linux commit a07b20004793d8926f78d63eb5980559f7813404 vfs: syscall: Add open_tree(2) to reference or clone a mount linux commit 2db154b3ea8e14b04fee23e3fdfd5e9d17fbc6ae vfs: syscall: Add move_mount(2) to move mounts around linux commit 24dcb3d90a1f67fe08c68a004af37df059d74005 vfs: syscall: Add fsopen() to prepare for superblock creation linux commit ecdab150fddb42fe6a739335257949220033b782 vfs: syscall: Add fsconfig() for configuring and managing a context linux commit 93766fbd2696c2c4453dd8e1070977e9cd4e6b6d vfs: syscall: Add fsmount() to create a mount for a superblock linux commit cf3cba4a429be43e5527a3f78859b1bfd9ebc5fb vfs: syscall: Add fspick() to select a superblock for reconfiguration linux commit 9c8ad7a2ff0bfe58f019ec0abc1fb965114dde7d uapi, x86: Fix the syscall numbering of the mount API syscalls [ver #2] linux commit d8076bdb56af5e5918376cd1573a6b0007fc1a89 uapi: Wire up the mount API syscalls on non-x86 arches [ver #2]
2019-09-11fcntl.h: add AT_RECURSIVE from linux v5.2Szabolcs Nagy1-0/+1
apply open_tree with OPEN_TREE_CLONE call to the entire subtree, see linux commit a07b20004793d8926f78d63eb5980559f7813404 vfs: syscall: Add open_tree(2) to reference or clone a mount
2019-09-11fcntl.h: add AT_STATX_ statx sync flag definitionsSzabolcs Nagy1-0/+4
see linux commit a528d35e8bfcc521d7cb70aaf03e1bd296c8493f statx: Add a system call to make enhanced file info available these are linux specific and not reserved names for fcntl.h so they are under _BSD_SOURCE|_GNU_SOURCE.
2019-09-11sched.h: add CLONE_PIDFD from linux v5.2Szabolcs Nagy1-0/+1
when set a pidfd is stored in parent_tidptr, see linux commit b3e5838252665ee4cfa76b82bdf1198dca81e5be clone: add CLONE_PIDFD
2019-09-11netinet/if_ether.h: add ETH_P_DSA_8021Q from linux v5.2Szabolcs Nagy1-0/+1
ethertype for fake VLAN header for DSA, see linux commit bf5bc3ce8a8f32a0d45b6820ede8f9fc3e9c23df ether: Add dedicated Ethertype for pseudo-802.1Q DSA tagging
2019-09-08honor __WCHAR_TYPE__ on archs with legacy long definition of wchar_tRich Felker4-0/+16
historically, a number of 32-bit archs used long rather than int for wchar_t, for no good reason. GCC still uses the historical types, but clang replaced them all with int, and it seems PCC uses int too. mismatching the compiler's type for wchar_t is not an option due to wide string literals. note that the mismatch does not affect C++ ABI since wchar_t is its own builtin type/keyword in C++, distinct from both int and long, not a typedef. i386 already worked around this by honoring __WCHAR_TYPE__ if defined by the compiler, and only using the official legacy ABI type if not. add the same to the other affected archs. it might make sense at some point to switch to using int as the default if __WCHAR_TYPE__ is not defined, if the expectations is that new compilers will treat int as the correct choice, but it's unlikely that the case where __WCHAR_TYPE__ is undefined will ever be used anyway. I actually wanted to move the definition of wchar_t to the top-level shared alltypes.h.in, using __WCHAR_TYPE__ and falling back to int if not defined, but that can't be done without assuming all compilers define __WCHAR_TYPE__ thanks to some pathological archs where the ABI has wchar_t as an unsigned type.
2019-09-06synchronously clean up pthread_create failure due to scheduling errorsRich Felker1-13/+18
previously, when pthread_create failed due to inability to set explicit scheduling according to the requested attributes, the nascent thread was detached and made responsible for its own cleanup via the standard pthread_exit code path. this left it consuming resources potentially well after pthread_create returned, in a way that the application could not see or mitigate, and unnecessarily exposed its existence to the rest of the implementation via the global thread list. instead, attempt explicit scheduling early and reuse the failure path for __clone failure if it fails. the nascent thread's exit futex is not needed for unlocking the thread list, since the thread calling pthread_create holds the thread list lock the whole time, so it can be repurposed to ensure the thread has finished exiting. no pthread_exit is needed, and freeing the stack, if needed, can happen just as it would if __clone failed.
2019-09-06set explicit scheduling for new thread from calling thread, not selfRich Felker1-21/+12
if setting scheduling properties succeeds, the new thread may end up with lower priority than the caller, and may be unable to continue running due to another intermediate-priority thread. this produces a priority inversion situation for the thread calling pthread_create, since it cannot return until the new thread reports success. originally, the parent was responsible for setting the new thread's priority; commits b8742f32602add243ee2ce74d804015463726899 and 40bae2d32fd6f3ffea437fa745ad38a1fe77b27e changed it as part of trimming down the pthread structure. since then, commit 04335d9260c076cf4d9264bd93dd3b06c237a639 partly reversed the changes, but did not switch responsibilities back. do that now.
2019-09-06fix unsynchronized decrement of thread count on pthread_create errorRich Felker1-1/+2
commit 8f11e6127fe93093f81a52b15bb1537edc3fc8af wrongly documented that all changes to libc.threads_minus_1 were guarded by the thread list lock, but the decrement for failed SYS_clone took place after the thread list lock was released.
2019-08-30add public declaration for optreset under appropriate feature profilesRich Felker2-0/+2
commit 030e52639248ac8417a4934298caa78c21a228d1 added optreset, a BSD extension to getopt duplicating the functionality (also an extension) of setting optind to 0, but failed to provide a public declaration for it. according to the BSD documentation and headers, the application is not supposed to need to provide its own declaration.
2019-08-30add posix_spawn [f]chdir file actionsRich Felker5-0/+50
these are presently extensions, thus named with _np to match glibc and other implementations that provide them; however they are likely to be standardized in the future without the _np suffix as a result of Austin Group issue 1208. if so, both names will be kept as aliases.
2019-08-23add copy_file_range system call wrapperÁrni Dagur2-0/+9
2019-08-19fix clash between sys/user.h and kernel ptrace.h on powerpc[64], shRich Felker3-41/+13
due to historical accident/sloppiness in glibc, the powerpc, powerpc64, and sh versions of struct user, defined by sys/user.h, used struct pt_regs from the kernel asm/ptrace.h for their regs member. this made it impossible to define the type in an API-compatible manner without either including asm/ptrace.h like glibc does (contrary to our policy of not depending on kernel headers), or clashing with asm/ptrace.h's definition of struct pt_regs if both headers are included (which is almost always the case in software using sys/user.h). for a long time I viewed this problem as having no reasonable fix. I even explored the possibility of having the powerpc[64] and sh versions of user.h just include the kernel header (breaking with policy), but that looked like it might introduce new clashes with sys/ptrace.h. and it would also bring in a lot of additional cruft that makes no sense for sys/user.h to expose. glibc goes out of its way to suppress some of that with #undef, possibly leading to different problems. this is a rabbit-hole that should be explored no further. as it turns out, however, nothing actually uses struct user sufficiently to care about the type of the regs member; most software including sys/user.h does not even use struct user at all. so, the problem can be fixed just by doing away with the insistence on strict glibc API compatibility for the struct tag of the regs member. rather than renaming the tag, which might lead to the new name entering use as API, simply use an untagged structure inside struct user with the same members/layout as struct pt_regs. for sh, struct pt_dspregs is just removed entirely since it was not used.
2019-08-17fix external dummy_lock symbol inadvertently introduced in sigactionRich Felker1-1/+1
commit 9b14ad541068d4f7d0be9bcd1ff4c70090d868d3 introduced this namespace violation.
2019-08-14remove sporadic server members from struct sched_paramRich Felker1-4/+6
these members are associated with an unsupported option group. with time_t changing size on 32-bit archs, all interfaces taking struct sched_param arguments would need redirection and compat shims in order to be able to continue offering these members, for no benefit. just convert them to reserved space instead.
2019-08-13re-add ELF gregs and fpregs types to riscv64 user.hKhem Raj1-0/+8
d493206de7df4db07ad34f24701539ba0a6ed38c deleted all the content of user.h, but sys/procfs.h expects this from sys/user.h threfore we retain the non conflicting parts
2019-08-13fix regression whereby main thread didn't get TLS relocationsRich Felker1-7/+13
commit ffab43602b5900c86b7040abdda8ccf6cdec95f5 broke this by moving relocations after not only the allocation of storage for the main thread's static TLS, but after the copying of the TLS image. thus, relocation results were not reflected in the main thread's copy. this could be fixed by calling __reset_tls after relocations, but instead split the allocation and installation before/after relocations so that there's not a redundant copy. due to commit 71af5309874269bcc9e4b84ea716fab33d888c1d, updating of static_tls_cnt needs to be kept with allocation of static TLS, before relocations, rather than after installation.
2019-08-13fix accidentlly-external cmp symbol introduced with catgetsRich Felker1-1/+1
commit 7590203c486d9002522019045d34ee3dee0a66f5 omitted static here.
2019-08-12make relocation time symbol lookup and dlsym consistentSzabolcs Nagy1-53/+31
Using common code path for all symbol lookups fixes three dlsym issues: - st_shndx of STT_TLS symbols were not checked and thus an undefined tls symbol reference could be incorrectly treated as a definition (the sysv hash lookup returns undefined symbols, gnu does not, so should be rare in practice). - symbol binding was not checked so a hidden symbol may be returned (in principle STB_LOCAL symbols may appear in the dynamic symbol table for hidden symbols, but linkers most likely don't produce it). - mips specific behaviour was not applied (ARCH_SYM_REJECT_UND) so undefined symbols may be returned on mips. always_inline is used to avoid relocation performance regression, the code generation for find_sym should not be affected.
2019-08-12ldso: correct condition for local symbol handling in do_relocsRich Felker1-1/+1
commit 7a9669e977e5f750cf72ccbd2614f8b72ce02c4c added use of the symbol reference as the definition, in place of performing a lookup, for STT_SECTION symbol references that were first found used in FDPIC. such references may happen in certain other cases, such as local-dynamic TLS and with relocation types that require a symbol but that are being used for non-symbolic purposes, like the powerpc unaligned address relocations. in all such cases I'm aware of, the symbol referenced is a section symbol (STT_SECTION); however, the important semantic property is not its being a section, but rather its binding local (STB_LOCAL). check the latter instead of the former for greater generality and semantic correctness.
2019-08-11add support for powerpc/powerpc64 unaligned relocationsSamuel Holland4-0/+6
R_PPC_UADDR32 (R_PPC64_UADDR64) has the same meaning as R_PPC_ADDR32 (R_PPC64_ADDR64), except that its address need not be aligned. For powerpc64, BFD ld(1) will automatically convert between ADDR<->UADDR relocations when the address is/isn't at its native alignment. This will happen if, for example, there is a pointer in a packed struct. gold and lld do not currently generate R_PPC64_UADDR64, but pass through misaligned R_PPC64_ADDR64 relocations from object files, possibly relaxing them to misaligned R_PPC64_RELATIVE. In both cases (relaxed or not) this violates the PSABI, which defines the relevant field type as "a 64-bit field occupying 8 bytes, the alignment of which is 8 bytes unless otherwise specified." All three linkers violate the PSABI on 32-bit powerpc, where the only difference is that the field is 32 bits wide, aligned to 4 bytes. Currently musl fails to load executables linked by BFD ld containing R_PPC64_UADDR64, with the error "unsupported relocation type 43". This change provides compatibility with BFD ld on powerpc64, and any static linker on either architecture that starts following the PSABI more closely.
2019-08-11ldso: remove redundant runtime checks in static TLS logicRich Felker1-2/+2
as a result of commit ffab43602b5900c86b7040abdda8ccf6cdec95f5, static_tls_cnt is now valid during relocations at program startup, so it's no longer necessary to condition the check against static_tls_cnt on this being a runtime (dlopen) relocation.
2019-08-11ldso: fix calloc misuse allocating initial tlsRich Felker1-5/+7
this is analogous to commit 2f1f51ae7b2d78247568e7fdb8462f3c19e469a4, and should have been caught at the same time since it was right next to the code moved in that commit. between final stage 3 reloc_all and the jump to the main program's entry point, it is not valid to call any functions which may be interposed by the application; doing so results in execution of application code before ctors have run, and on fdpic archs, before the main program's fdpic self-fixups have taken place, which will produce runaway wrong execution.
2019-08-08add secure_getenv functionPetr Vaněk2-0/+9
This function is a GNU extension introduced in glibc 2.17.
2019-08-07in clock_getres, check for null pointer before storing resultRich Felker1-1/+1
POSIX allows a null pointer, in which case the function only checks the validity of the clock id argument.
2019-08-07remove spurious null check in clock_settimeRich Felker1-1/+1
at the point of this check, the pointer has already been dereferenced. clock_settime is not defined for null pointer arguments.
2019-08-07fix regression in recvmmsg with no timeoutRich Felker1-1/+1
somewhat analogous to commit d0b547dfb5f7678cab6bc39dd736ed6454357ca4, but here the omission of the null timeout check was in the time64 syscall code path. this code is not yet used except on x32.
2019-08-07add non-stub implementation of catgets localization functionsRich Felker3-3/+114
these accept the netbsd/openbsd message catalog file format, consisting of a sorted list of set headers and a sorted list of message headers for each set, admitting trivial binary search for lookups. the gnu format was not chosen because it's unusably bad. it does not admit efficient (log time or better) lookups; rather, it requires linear search or hash table lookups, and the hash function is awful: it's literally set_id*msg_id.
2019-08-07fix regression in select with no timeoutRich Felker1-1/+2
commit 722a1ae3351a03ab25010dbebd492eced664853b inadvertently passed a copy of {s,us} to the syscall even if the timeout argument tv was null, thereby causing immediate timeout (polling) in place of unlimited timeout. only archs using SYS_select were affected.
2019-08-07fix failure of glob to match broken symlinks under some conditionsRich Felker1-5/+12
when the pattern ended with one or more literal path components, or when the GLOB_MARK flag was passed to request that glob flag directory results and the type obtained by readdir was unknown or inconclusive (symlink), the stat function was called to evaluate existence and/or determine type. however, stat fails with ENOENT for broken symlinks, and this caused the match to be omitted from the results. instead, use stat only for the unknown/inconclusive cases with GLOB_MARK, and otherwise, or if stat fails, use lstat existence still needs to be determined. this minimizes the number of costly syscalls, performing both only in the case where GLOB_MARK is in use and there is a final literal path component which is a broken symlink. based on/simplified from patch by James Y Knight.
2019-08-06remove riscv64 bits/user.h contentsRich Felker1-43/+0
the contents conflicted with asm/ptrace.h. glibc does not provide anything in user.h for riscv, so software cannot be depending on it. simplified from patch submitted by Baruch Siach.
2019-08-06fix risc64 conflict with kernel headersBaruch Siach1-8/+8
Rename user registers struct definitions to avoid conflict with the asm/ptrace.h kernel header that defines the same structs. Use the __riscv_mc prefix as glibc does.
2019-08-06in arm cancellation point asm, don't unnecessarily preserve link registerPatrick Oppenlander1-4/+4
The only reason we needed to preserve the link register was because we were using a branch-link instruction to branch to __cp_cancel. Replacing this with a branch means we can avoid the save/restore as the link register is no longer modified.
2019-08-06glob: implement GLOB_TILDE and GLOB_TILDE_CHECKIsmael Luceno2-1/+44
2019-08-05use setitimer function rather than syscall to implement alarmRich Felker1-3/+3
otherwise alarm will break on 32-bit archs when time_t is changed to 64-bit. a second itimerval object is introduced for retrieving the old value, since the setitimer function has restrict-qualified arguments.
2019-08-05fix build regression in i386 asm for atan2, atan2fRich Felker2-2/+2
commit f3ed8bfe8a82af1870ddc8696ed4cc1d5aa6b441 inadvertently removed labels that were still needed.
2019-08-05fix x87 stack imbalance in corner cases of i386 math asmRich Felker8-44/+14
commit 31c5fb80b9eae86f801be4f46025bc6532a554c5 introduced underflow code paths for the i386 math asm, along with checks on the fpu status word to skip the underflow-generation instructions if the underflow flag was already raised. unfortunately, at least one such path, in log1p, returned with 2 items on the x87 stack rather than just 1 item for the return value. this is a violation of the ABI's calling convention, and could cause subsequent floating point code to produce NANs due to x87 stack overflow. if floating point results are used in flow control, this can lead to runaway wrong code execution. rather than reviewing each "underflow already raised" code path for correctness, remove them all. they're likely slower than just performing the underflow code unconditionally, and significantly more complex. all of this code should be ripped out and replaced by C source files with inline asm. doing so would preclude this kind of error by having the compiler perform all x87 stack register allocation and stack manipulation, and would produce comparable or better code. however such a change is a much larger project.
2019-08-05fix regression in clock_gettime on 32-bit archs without vdsoRich Felker1-0/+1
commit 72f50245d018af0c31b38dec83c557a4e5dd1ea8 broke this by creating a code path where r is uninitialized.
2019-08-03update riscv64 syscall numbers to linux v5.1Rich Felker1-0/+8
commit f3f96f2daa4d00f0e38489fb465cd0244b531abe added these for the rest of the archs, but the patch it corresponded to missed riscv64 since riscv64 was not yet upstream at the time. this caused commit dfc81828f7ab41da08f744c44117a1bb20a05749 to break riscv64 build, due to a wrong assumption that SYS_statx was unconditionally defined.
2019-08-02clock_gettime: add support for 32-bit vdso with 64-bit time_tRich Felker1-0/+32
this fixes a major upcoming performance regression introduced by commit 72f50245d018af0c31b38dec83c557a4e5dd1ea8, whereby 32-bit archs would lose vdso clock_gettime after switching to 64-bit time_t, unless the kernel supports time64 and provides a time64 version of the vdso function. this would incur not just one but two syscalls: first, the failed time64 syscall, then the fallback time32 one. overflow of the 32-bit result is detected and triggers a revert to syscalls. normally, on a system that's not Y2038-ready, this would still overflow, but if the process has been migrated to a time64-capable kernel or if the kernel has been hot-patched to add time64 syscalls, it may conceivably work.
2019-08-02move IPC_STAT definition to a new bits/ipcstat.h fileRich Felker11-3/+11
otherwise, 32-bit archs that could otherwise share the generic bits/ipc.h would need to duplicate the struct ipc_perm definition, obscuring the fact that it's the same. sysvipc is not widely used and these headers are not commonly included, so there is no performance gain to be had by limiting the number of indirectly included files here. files with the existing time32 definition of IPC_STAT are added to all current 32-bit archs now, so that when it's changed the change will show up as a change rather than addition of a new file where it's less obvious that the value is changing vs the generic one that was used before.
2019-08-02fix missing declarations for pthread_join extensions in source fileRich Felker1-0/+1
per policy, define the feature test macro to get declarations for the pthread_tryjoin_np and pthread_timedjoin_np functions. in the past this has been only for checking; with 32-bit archs getting 64-bit time_t it will also be necessary for symbols to get redirected correctly.
2019-08-02allow archs to define IPC_STAT, propagate time64 bit to other macrosRich Felker4-6/+8
to make use of {sem,shm,msg}ctl IPC_STAT functionality to provide 64-bit time_t on 32-bit archs, IPC_STAT and related macros must be defined with bit 8 (0x100) set. allow archs to define IPC_STAT in bits/ipc.h, and define the other macros in terms of it so that they all get the same value of the time64 bit.
2019-08-02clock_gettime: add time64 syscall support, decouple 32-bit time_tRich Felker1-0/+19
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[2] array, then copied into the timespec, to remove the assumption that time_t is the same as long. vdso clock_gettime is still used in place of a syscall if available. 32-bit archs with 64-bit time_t must use the time64 version of the vdso function; if it's not available, performance will significantly suffer. support for both vdso functions could be added, but would break the ability to move a long-lived process from a pre-time64 kernel to one that can outlast Y2038 with checkpoint/resume, at least without added hacks to identify that the 32-bit function is no longer usable and stop using it (e.g. by seeing negative tv_sec). this possibility may be explored in future work on the function.
2019-08-02clock_adjtime: add time64 support, decouple 32-bit time_t, fix x32Rich Felker1-0/+110
the 64-bit/time64 version of the syscall is not API-compatible with the userspace timex structure definition; fields specified as long have type long long. so when using the time64 syscall, we have to convert the entire structure. this was always the case for x32 as well, but went unnoticed, meaning that clock_adjtime just passed junk to the kernel on x32. it should be fixed now. for the fallback case, we avoid encoding any assumptions about the new location of the time member or naming of the legacy slots by accessing them through a union of the kernel type and the new userspace type. the only assumption is that the non-time members live at the same offsets as in the (non-time64, long-based) kernel timex struct. this property saves us from having to convert the whole thing, and avoids a lot of additional work in compat shims. the new code is statically unreachable for now except on x32, where it fixes major brokenness. it is permanently unreachable on 64-bit.
2019-07-31ioctl: add fallback for new time64 SIOCGSTAMP[NS]Rich Felker3-1/+34
without this, the SIOCGSTAMP and SIOCGSTAMPNS ioctl commands, for obtaining timestamps, would stop working on pre-5.1 kernels after time_t is switched to 64-bit and their values are changed to the new time64 versions. new code is written such that it's statically unreachable on 64-bit archs, and on existing 32-bit archs until the macro values are changed to activate 64-bit time_t.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2024-11-06 08:37:47 +0000