about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
...
* prepare struct sched_param for change in time_t definitionRich Felker2019-10-281-0/+4
| | | | | | | | | | the time_t members in struct sched_param are just reserved space to preserve size and alignment. when time_t changes to 64-bit on 32-bit archs, this structure should not change. make definition conditional on _REDIR_TIME64 to match the size of the old time_t, which can be assumed to be long if _REDIR_TIME64 is defined.
* add time64 symbol name redirects to public headers, under arch controlRich Felker2019-10-2821-0/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | a _REDIR_TIME64 macro is introduced, which the arch's alltypes.h is expected to define, to control redirection of symbol names for interfaces that involve time_t and derived types. this ensures that object files will only be linked to libc interfaces matching the ABI whose headers they were compiled against. along with time32 compat shims, which will be introduced separately, the redirection also makes it possible for a single libc (static or shared) to be used with object files produced with either the old (32-bit time_t) headers or the new ones after 64-bit time_t switchover takes place. mixing of such object files (or shared libraries) in the same program will also be possible, but must be done with care; ABI between libc and a consumer of the libc interfaces is guaranteed to match by the the symbol name redirection, but pairwise ABI between consumers of libc that define interfaces between each other in terms of time_t is not guaranteed to match. this change adds a dependency on an additional "GNU C" feature to the public headers for existing 32-bit archs, which is generally undesirable; however, the feature is one which glibc has depended on for a long time, and thus which any viable alternative compiler is going to need to provide. 64-bit archs are not affected, nor will future 32-bit archs be, regardless of whether they are "new" on the kernel side (e.g. riscv32) or just newly-added (e.g. a new sparc or xtensa port). the same applies to newly-added ABIs for existing machine-level archs.
* add missing m68k user.h/procfs.h regset typesRich Felker2019-10-281-0/+5
|
* update case mappings to unicode 12.1.0Rich Felker2019-10-251-85/+92
|
* update ctype data to unicode 12.1.0u_quark2019-10-254-201/+232
|
* overhaul wide character case mapping implementationRich Felker2019-10-252-290/+345
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | the existing implementation of case mappings was very small (typically around 1.5k), but unmaintainable, requiring manual addition of new case mappings with each new edition of Unicode. often, it turned out that newly-added case mappings were not easily representable in the existing tightly-constrained table structures, requiring new hacks to be invented and delaying support for new characters. the new implementation added here follows the pattern used for character class membership, with a two-level table allowing Unicode blocks for which no data is needed to be elided. however, rather than single-bit data, each character maps to a one of up to 6 case-mapping rules available to its block, where 6 is floor(cbrt(256)) and allow 3 characters to be represented per byte (vs 8 with bit tables). blocks that would need more than 6 rules designate one as an exception and let lookup pass into a binary search of exceptional cases for the block. the number 6 was chosen empirically; many blocks would be ok with 4 rules (uncased, lower, upper, possible exceptions), some even just with 2, but the latter are rare and fitting 4 characters per byte rather than 3 does not save significant space. moreover, somewhat surprisingly, there are sufficiently many blocks where even 4 rules don't suffice without a lot of exceptions (blocks where some case pairs are laced, others offset) that originally I was looking at supporting variable-width tables, with 1-, 2-, or 3-bit entries, thereby allowing blocks with 8 rules. as implemented in my experiments, that version was significantly larger and involved more memory accesses/cache lines. improvements in size at the expense of some performance might be possible by utilizing iswalpha data or merging the table of case mapping identity with alphabetic identity. these were explored somewhat when the code was first written, and might be worth revisiting in the future.
* add missing case mapping between U+03F3 and U+037FRich Felker2019-10-251-0/+1
| | | | | | somehow this seems to have been overlooked. add it now so that subsequent overhaul of case mapping implementation will not introduce a functional change at the same time.
* fix errno for posix_openpt with no free ptys availableRich Felker2019-10-241-1/+3
| | | | linux fails the open with ENOSPC, but POSIX mandates EAGAIN.
* adjust struct timespec definition to be time64-readyRich Felker2019-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | for time64 support on 32-bit archs, the kernel interfaces use a timespec layout padded to match the representation of a pair of 64-bit values, which requires endian-specific padding. use of an ordinary, non-bitfield, named member for the padding is undesirable because, on big endian archs, it would alter the interpretation of traditional (non-designated) initializers of the form {s,ns}, initializing the padding instead of the tv_nsec member. unnamed bitfield members solve this problem by not taking part in initialization, and were the expected solution when the kernel interfaces were designed. however, they also have further advantages which we take advantage of here: positioning of the padding could be controlled by having a preprocessor conditional with separate definitions of struct timespec for little and big endian, but whether padding should appear at all is a function of whether time_t is larger than long. this condition is not something the preprocessor can determine unless we were to define a new macro specifically for that purpose. by using unnamed bitfield members instead of ordinary named members, we can arrange for the size of the padding to collapse to zero when it should not be present, just by using sizeof(time_t) and sizeof(long) in the bitfield width expression, which can be any integer constant expression.
* clock_adjtime: generalize time64 not to assume old struct layout matchRich Felker2019-10-201-11/+46
| | | | | | | | | | | | | commit 2b4fd6f75b4fa66d28cddcf165ad48e8fda486d1 added time64 for this function, but did so with a hidden assumption that the new time64 version of struct timex will be layout-compatible with the old one. however, there is little benefit to doing it that way, and the cost is permanent special-casing of 32-bit archs with 64-bit time_t in the public interface definitions. instead, do a full translation of the structure going in and out. this commit is actually a revision to an earlier uncommited version of the code.
* wait4, getrusage: add time64/x32 variantRich Felker2019-10-192-3/+61
| | | | | | | | | | | | | | | | | | presently the kernel does not actually define time64 versions of these syscalls, and they're not really needed except to represent extreme cpu time usage. however, x32's versions of the syscalls already behave as time64 ones, meaning the functions were broken on x32 if the caller used any part of the rusage result other than ru_utime and ru_stime. commit 7e8171143124f7f510db555dc6f6327a965a3e84 made it possible to fix this by treating x32's syscalls as time64 versions. in the non-time64-syscall case, make the syscall with the rusage destination pointer adjusted so that all members but the timevals line up between the libc and kernel structures. on 64-bit archs, or present 32-bit archs with 32-bit time_t, the timevals will line up too and no further work is needed. for future 32-bit archs with 64-bit time_t, the timevals are copied into place, contingent on time_t being larger than long.
* internally, define time64 rusage syscalls on x32 as the existing onesRich Felker2019-10-191-0/+2
| | | | | | | | | | | | | | | this is analogous to commit 40aa18d55ab763e69ad16d0cf1cebea708ffde47. so far, there are not any actual time64 versions of the rusage syscalls (getrusage and wait4) and might never be. however, the existing x32 ones behave the way time64 versions would if they existed: using 64-bit slots in place of all longs. presently, wait4 and getrusage are broken on x32, storing the timevals correctly but messing up everything else due to the long/kernel-long mismatch. this would be a huge buffer overflow if not for the 16 reserved slots we left long ago, which suffice to prevent 14 double-sized longs from overflowing into unrelated memory. this commit will make it possible to fix them.
* use struct pt_regs * rather than void * for powerpc[64] sigcontext regsRich Felker2019-10-192-2/+2
| | | | | | | | this is to match the kernel and glibc interfaces. here, struct pt_regs is an incomplete type, but that's harmless, and if it's completed by inclusion of another header then members of the struct pointed to by the regs member can be accessed directly without going through a cast or intermediate pointer object.
* fix fpregset_t type on powerpc64Rich Felker2019-10-191-5/+1
| | | | | | | | | | the userspace ucontext API has this as an array rather than a structure. commit 3c59a868956636bc8adafb1b168d090897692532 fixed the corresponding mistake for vrregset_t, namely that the original powerpc64 port used a mix of types from 32-bit powerpc and powerpc64 rather than matching the 64-bit types.
* fix return value of ungetc when argument is outside unsigned char rangeRich Felker2019-10-181-1/+1
| | | | | | | | | | aside from the special value EOF, ungetc is specified to accept and convert values outside the range of unsigned char. conversion takes place automatically as part of assignment when storing into the buffer, but the return value is also required to be the resulting converted value, and this requirement was not satisfied. simplified from patch by Wang Jianjian.
* fix incorrect use of fabs on long double operand in floatscan.cRich Felker2019-10-181-4/+1
| | | | | | | | | | | | | | based on patch by Dan Gohman, who caught this via compiler warnings. analysis by Szabolcs Nagy determined that it's a bug, whereby errno can be set incorrectly for values where the coercion from long double to double causes rounding. it seems likely that floating point status flags may be set incorrectly as a result too. at the same time, clean up use of preprocessor concatenation involving LDBL_MANT_DIG, which spuriously depends on it being a single unadorned decimal integer literal, and instead use the equivalent formulation 2/LDBL_EPSILON. an equivalent change on the printf side was made in commit bff6095d915f3e41206e47ea2a570ecb937ef926.
* move pthread types out of per-arch alltypes.hRich Felker2019-10-1717-128/+8
| | | | | | | | | | | policy has long been that these definitions are purely a function of whether long/pointer is 32- or 64-bit, and that they are not allowed to vary per-arch. move the definition to the shared alltypes.h.in fragment, using integer constant expressions in terms of sizeof to vary the array dimensions appropriately. I'm not sure whether this is more or less ugly than using preprocessor conditionals and two sets of definitions here, but either way is a lot less ugly than repeating the same thing for every arch.
* define LONG_MAX via arch alltypes.h, strip down bits/limits.hRich Felker2019-10-1734-117/+35
| | | | | | | | | | | | | | | | | | | | | LLONG_MAX is uniform for all archs we support and plenty of header and code level logic assumes it is, so it does not make sense for limits.h bits mechanism to pretend it's variable. LONG_BIT can be defined in terms of LONG_MAX; there's no reason to put it in bits. by moving LONG_MAX definition to __LONG_MAX in alltypes.h and moving LLONG_MAX out of bits, there are now no plain-C limits that are defined in the bits header, so the bits header only needs to be included in the POSIX or extended profiles. this allows the feature test macro logic to be removed from the bits header, facilitating a long-term goal of getting such logic out of bits. having __LONG_MAX in alltypes.h will allow further generalization of headers. archs without a constant PAGESIZE no longer need bits/limits.h at all.
* make endian.h expose unprefixed macros, functions in standard profileRich Felker2019-10-171-16/+20
| | | | | | | | | the resolution of Austin Group issue #162 adds endian.h as a standard header for future versions of the standard, making it no longer acceptable for some of the functionality to be hidden behind _BSD_SOURCE or _GNU_SOURCE. the definitions of the [lb]etoh{16,32,64} function-like macros are kept conditional since they are alternate names which the standard did not adopt.
* remove use of endian.h from arch reloc.h headers, clean upRich Felker2019-10-179-24/+0
| | | | | | | | | | building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea, __BYTE_ORDER is now available wherever alltypes.h is included. since reloc.h is only used from src/internal/dynlink.h, it can be assumed that __BYTE_ORDER is exposed. reloc.h is not permitted to be included in other contexts, and generally, like most arch headers, lacks inclusion guards that would allow such usage. the mips64 version mistakenly included such guards; they are removed for consistency.
* remove indirect use of endian.h from public headersRich Felker2019-10-1712-18/+0
| | | | | | | | building on commit 97d35a552ec5b6ddf7923dd2f9a8eb973526acea, __BYTE_ORDER is now available wherever alltypes.h is included. endian.h should not be used since, in the future, it will expose identifiers that are not in the reserved namespace for the headers which were previously using it.
* move __BYTE_ORDER definition to alltypes.hRich Felker2019-10-1734-69/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | this change is motivated by the intersection of several factors. presently, despite being a nonstandard header, endian.h is exposing the unprefixed byte order macros and functions only if _BSD_SOURCE or _GNU_SOURCE is defined. this is to accommodate use of endian.h from other headers, including bits headers, which need to define structure layout in terms of endianness. with time64 switch-over, even more headers will need to do this. at the same time, the resolution of Austin Group issue 162 makes endian.h a standard header for POSIX-future, requiring that it expose the unprefixed macros and the functions even in standards-conforming profiles. changes to meet this new requirement would break existing internal usage of endian.h by causing it to violate namespace where it's used. instead, have the arch's alltypes.h define __BYTE_ORDER, either as a fixed constant or depending on the right arch-specific predefined macros for determining endianness. explicit literals 1234 and 4321 are used instead of __LITTLE_ENDIAN and __BIG_ENDIAN so that there's no danger of getting the wrong result if a macro is undefined and implicitly evaluates to 0 at the preprocessor level. the powerpc (32-bit) bits/endian.h being removed had logic for varying endianness, but our powerpc arch has never supported that and has always been big-endian-only. this logic is not carried over to the new __BYTE_ORDER definition in alltypes.h.
* remove per-arch definitions for va_listRich Felker2019-10-1717-48/+3
| | | | | | | now that commit f7f1079796abc6f97c69521d2334e9c7d3945dd8 removed the legacy i386 conditional definition, va_list is in no way arch-specific, and has no reason to be in the future. move it to the shared part of alltypes.h.in
* remove i386 support for legacy struct __va_listRich Felker2019-10-171-5/+0
| | | | | | | | commit ffaaa6d230512f3a7f3d040b943517728f3dc3cf removed the corresponding stdarg.h support for compilers without va_list builtins, but failed to remove the alternate type definition, leaving incorrect va_list definitions in place with compilers that don't define __GNUC__ with a value >= 3.
* mips: add single-instruction math functionsinfo@mobile-stream.com2019-10-144-0/+64
| | | | | | | SQRT.fmt exists on MIPS II+ (float), MIPS III+ (double). ABS.fmt exists on MIPS I+ but only cores with ABS2008 flag in FCSR implement the required behaviour.
* fix cacosh results for arguments with negative imaginary partMichael Morrell2019-10-143-3/+12
|
* release 1.1.24 v1.1.24Rich Felker2019-10-132-1/+50
|
* math: fix signed int left shift ub in sqrtSzabolcs Nagy2019-10-132-4/+2
| | | | | | | Both sqrt and sqrtf shifted the signed exponent as signed int to adjust the bit representation of the result. There are signed right shifts too in the code but those are implementation defined and are expected to compile to arithmetic shift on supported compilers and targets.
* fix aliasing-based undefined behavior in mbsrtowcsRich Felker2019-10-131-2/+8
| | | | | | | | | | | mbsrtowcs contains "vectorized" loops to quickly step over bytes without the high bit set; these have undefined behavior by virtue of aliasing uint32_t over top of char data for the accesses. commit 4d0a82170a25464c39522d7190b9fe302045ddb2 fixed the corresponding usage in string functions by using the may_alias attribute conditional on __GNUC__ and disabled the vectorized code in its absence. do the same for mbsrtowcs.
* add Arm to the copyright fileSzabolcs Nagy2019-10-061-1/+2
| | | | | | Several math functions are now from the ARM optimized-routines repo licensed under standard MIT terms and copyrighted by Arm Limited, so mention this in the COPYRIGHT too.
* reintroduce riscv64 struct sigcontextRich Felker2019-10-021-6/+10
| | | | | | | | commit ab3eb89a8b83353cdaab12ed017a67a7730f90e9 removed it as part of correcting the mcontext_t definition, but there is still code using struct sigcontext and expecting the member names present in it, most notably libgcc_eh. almost all such usage is incorrect, but bring back struct sigcontext at least for now so as not to introduce regressions.
* fix riscv64 elf_fpregset_t type and member names mismatchRich Felker2019-09-291-5/+2
| | | | | | | | | | | | | | | | | in order for sys/procfs.h (provided by sys/user.h) to be useful, it needs to match the API its consumers (gdb, etc.) expect, including the member names established by glibc. this partly reverts commit 29e8737f81ccc9fbadcf61a75318aa3d0516aafa, which partly reverted d493206de7df4db07ad34f24701539ba0a6ed38c, eliminating struct user_fpregs_struct which seems to have had no precedent and using union __riscv_mc_fp_state for elf_fpregset_t. this requires indirect inclusion of signal.h to make union __riscv_mc_fp_state visible, but being that these are nonstandard "junk" headers with no official restrictions on what they can pull in, that's no big deal. split off and expanded from patch by Khem Raj.
* fix riscv64 signal.h namespace violations and ucontext API mismatchesRich Felker2019-09-292-27/+20
| | | | | | | | | | | | | | | | | | | | | the top-level mcontext_t member names were namespace-violating in standards profiles before, and nested-level member names (some of them single-letter) were egregiously bad namespace impositions even in non-strict profiles. moreover, they mismatched those used in the public API first defined in glibc, breaking any code making use of them. unlike most archs, the public API used in glibc for riscv mcontext_t members was designed to be namespace-safe, so we can and should expose the members regardless of feature test macros. only the typedefs for greg_t, gregset_t, and fpregset_t need to be protected behind FTMs. the struct tags for mcontext_t and ucontext_t are also changed. for mcontext_t this is necessary to make the common definition across profiles namespace-safe. for ucontext_t, it's just a matter of matching the tag from the glibc-defined API. these changes are split off and expanded from a patch by Khem Raj.
* remove remaining traces of __tls_get_newSzabolcs Nagy2019-09-295-12/+1
| | | | | | | | | | | | | | | | Some declarations of __tls_get_new were left in the code, even though the definition got removed in commit 9d44b6460ab603487dab4d916342d9ba4467e6b9 install dynamic tls synchronously at dlopen, streamline access this can make the build fail with ld: lib/libc.so: hidden symbol `__tls_get_new' isn't defined when libc.so is linked without --gc-sections, because a .hidden declaration in asm code creates a reference even if the symbol is not actually used.
* math: optimize lrint on 32bit targetsSzabolcs Nagy2019-09-271-1/+27
| | | | | | | | | | | | | | | lrint in (LONG_MAX, 1/DBL_EPSILON) and in (-1/DBL_EPSILON, LONG_MIN) is not trivial: rounding to int may be inexact, but the conversion to int may overflow and then the inexact flag must not be raised. (the overflow threshold is rounding mode dependent). this matters on 32bit targets (without single instruction lrint or rint), so the common case (when there is no overflow) is optimized by inlining the lrint logic, otherwise the old code is kept as a fallback. on my laptop an i486 lrint call is asm:10ns, old c:30ns, new c:21ns on a smaller arm core: old c:71ns, new c:34ns on a bigger arm core: old c:27ns, new c:19ns
* clean up mips (32-bit, o32) syscall asm constraintsRich Felker2019-09-271-31/+32
| | | | | | | | | | | | | | | | | | | | analogous to commit ddc7c4f936c7a90781072f10dbaa122007e939d0 for mips64 and n32, remove the hack to load the syscall number into $2 via asm, and use a constraint to let the compiler load it instead. now, only $4, $5, and $6 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. as before, $8, $9, and $10 are conditionally input-output registers for 5-, 6-, and 7-argument syscalls. their role in input is carrying in the values that will be stored on the stack for arguments 5-7. their role in output is carrying back whatever the kernel has clobbered them with, so that the compiler cannot assume they still contain the input values.
* document mips r6 in INSTALL fileRich Felker2019-09-271-1/+2
|
* fix mips setjmp/longjmp fpu state on r6, related issuesRich Felker2019-09-262-24/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mips32 has two fpu register file variants: FR=0 with 32 32-bit registers, where pairs of neighboring even/odd registers are used to represent doubles, and FR=1 with 32 64-bit registers, each of which can store a single or double. up through r5 (our "mips" arch), the supported ABI uses FR=0, but modern compilers generate "fpxx" model code that can safely operate with either model. r6, which is an incompatible but similar ISA, drops FR=0 and only provides the FR=1 model. as such, setjmp and longjmp, which depended on being able to save and restore call-saved doubles by storing and loading their 32-bit halves, were completely broken in the presence of floating point code on mips r6. to fix this, use the s.d and l.d mnemonics to store and load fpu registers. these expand to the existing swc1 and lwc1 instructions for pairs of 32-bit fpu registers on mips1, but on mips2 and later they translate directly to the 64-bit sdc1 and ldc1. with FR=0, sdc1 and ldc1 behave just like the pairs of swc1 and lwc1 instructions they replace, storing or loading the even/odd pair of fpu registers that can be treated as separate single-precision floats or as a unit representing a double. but with FR=1, they store/load individual 64-bit registers. this yields the ABI-correct behavior on mips r6, and should make linking of pre-r6 (plain "mips") code with "fp64" model code workable, although this is and will likely remain unsupported usage. in addition to the mips r6 problem this change fixes, reportedly clang's internal assembler refuses to assemble swc1 and lwc1 instructions for odd register indices when building for "fpxx" model (the default). this caused setjmp and longjmp not to build. by using the s.d and l.d forms, this problem is avoided too. as a bonus, code size is reduced everywhere but mips1.
* fix mips r6 syscall clobber lists not to include hi/lo registersRich Felker2019-09-263-16/+30
| | | | | | | | | | mips r6 (an incompatible isa from traditional mips) removes the hi and lo registers used for mul/div results. older gcc versions accepted them in the clobber list for asm, but their presence is incorrect and breaks on later versions. in the process of fixing this, the clobber list for 32-bit mips syscalls has been deduplicated via a macro like on mips64 and n32.
* arm: fix setjmp and longjmp asm for armv8-aSzabolcs Nagy2019-09-262-0/+14
| | | | | | | | | armv8 removed the coprocessor instructions other than cp14, so on an armv8 system the related hwcaps should never be set. new llvm complains about the use of coprocessor instructions in armv8-a mode (even though they are never executed at runtime), so ifdef them out when musl is built for armv8.
* fix data race in timer_create with SIGEV_THREAD notificationRich Felker2019-09-251-2/+2
| | | | | | | | | | | | in the timer thread start function, self->timer_id was accessed without synchronization; the timer thread could fail to see the store from the calling thread, resulting in timer_delete failing to delete the correct kernel-level timer. this fix is based on a patch by changdiankang, but with the load moved to after receiving the timer_delete signal rather than just after the start barrier, so as not to retain the possibility of data race with timer_delete.
* correct the operand specifiers in the riscv64 CAS routinesPalmer Dabbelt2019-09-251-2/+2
| | | | | | | | | | | | | | | | The operand sepcifiers in a_cas and a_cas_p for riscv64 were incorrect: there's a backwards branch in the routine, so despite tmp being written at the end of the assembly fragment it cannot be allocated in one of the input registers because the input values may be needed for another trip around the loop. For code that follows the guaranteed forward progress requirements, the backwards branch is rarely taken: SiFive's hardware only fails a store conditional on execptional cases (ie, instruction cache misses inside the loop), and until recently a bug in QEMU allowed back-to-back store conditionals to succeed. The bug has been fixed in the latest QEMU release, but it turns out that the fix caused this latent bug in musl to manifest.
* harden thread start with failed scheduling against broken __cloneRich Felker2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | commit 8a544ee3a2a75af278145b09531177cab4939b41 introduced a dependency of the failure path for explicit scheduling at thread creation on __clone's handling of the start function returning, which should result in SYS_exit. as noted in commit 05870abeaac0588fb9115cfd11f96880a0af2108, the arm version of __clone was broken in this case. in the past, the mips version was also broken; it was fixed in commit 8b2b61e0001281be0dcd3dedc899bf187172fecb. since this code path is pretty much entirely untested (previously only reachable in applications that call the public clone() and return from the start function) and consists of fragile per-arch asm, don't assume it works, at least not until it's been thoroughly tested. instead make the SYS_exit syscall from the start function's failure path.
* fix %lf in wprintfBrion Vibber2019-09-131-0/+2
| | | | | | | commit cc3a4466605fe8dfc31f3b75779110ac93055bc1 fixed this for printf but neglected to fix wprintf. Previously, %lf caused a failure to output.
* fix arm __tlsdesc_dynamic when built as thumb code without __ARM_ARCH>=5Rich Felker2019-09-111-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.
* fix arm __a_barrier_oldkuser when built as thumbRich Felker2019-09-111-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.
* fix code path where child function returns in arm __clone built as thumbRich Felker2019-09-111-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.
* aarch64: add HWCAP2 flags from linux v5.2Szabolcs Nagy2019-09-111-0/+8
| | | | | | | | | | AT_HWCAP2 flags, see linux commit 671db581815faf17cbedd7fcbc48823a247d90b1 arm64: Expose DC CVADP to userspace linux commit 06a916feca2b262ab0c1a2aeb68882f4b1108a07 arm64: Expose SVE2 features for userspace
* add new syscall numbers from linux v5.2Szabolcs Nagy2019-09-1116-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]
* fcntl.h: add AT_RECURSIVE from linux v5.2Szabolcs Nagy2019-09-111-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
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-11 19:28:23 +0000