about summary refs log tree commit diff
Commit message (Collapse)AuthorAgeFilesLines
* suppress null termination when fgets reads EOF with no dataRich Felker2014-09-041-1/+1
| | | | | | | | | the C standard requires that "the contents of the array remain unchanged" in this case. this patch also changes the behavior on read errors, but in that case "the array contents are indeterminate", so the application cannot inspect them anyway.
* fix dn_expand empty name handling and offsets to 0Szabolcs Nagy2014-09-041-6/+9
| | | | | | | | | | Empty name was rejected in dn_expand since commit 56b57f37a46dab432247bf29d96fcb11fbd02a6d which is a regression as reported by Natanael Copa. Furthermore if an offset pointer in a compressed name pointed to a terminating 0 byte (instead of a label) the returned name was not null terminated.
* add static_assert and hide noreturn, alignas, alignof from C++Szabolcs Nagy2014-08-273-0/+11
| | | | | add static_assert and protect the other new C11 keyword macros with #ifndef __cplusplus so they don't conflict with C++ keywords.
* add C11 floating-point characteristic macros to float.hSzabolcs Nagy2014-08-271-0/+7
| | | | C11 introduced *_DECIMAL_DIG and *_HAS_SUBNORM macros.
* add malloc_usable_size function and non-stub malloc.hRich Felker2014-08-252-0/+42
| | | | | | | | | | | | | | | | | | | | | | this function is needed for some important practical applications of ABI compatibility, and may be useful for supporting some non-portable software at the source level too. I was hesitant to add a function which imposes any constraints on malloc internals; however, it turns out that any malloc implementation which has realloc must already have an efficient way to determine the size of existing allocations, so no additional constraint is imposed. for now, some internal malloc definitions are duplicated in the new source file. if/when malloc is refactored to put them in a shared internal header file, these could be removed. since malloc_usable_size is conventionally declared in malloc.h, the empty stub version of this file was no longer suitable. it's updated to provide the standard allocator functions, nonstandard ones (even if stdlib.h would not expose them based on the feature test macros in effect), and any malloc-extension functions provided (currently, only malloc_usable_size).
* refrain from spinning on locks when there is already a waiterRich Felker2014-08-255-5/+5
| | | | | | | | | | if there is already a waiter for a lock, spinning on the lock is essentially an attempt to steal it from whichever waiter would obtain it via any priority rules in place, and is therefore undesirable. in the current implementation, there is always an inherent race window at unlock during which a newly-arriving thread may steal the lock from the existing waiters, but we should aim to keep this window minimal rather than enlarging it.
* spin before waiting on futex in mutex and rwlock lock operationsRich Felker2014-08-253-0/+20
|
* spin in sem_[timed]wait before performing futex waitRich Felker2014-08-251-0/+5
| | | | | | | | | empirically, this increases the maximum rate of wait/post operations between two threads by 20-150 times on machines I tested, including x86 and arm. conceptually, it makes sense to do some spinning because semaphores are intended to be usable as a notification mechanism between threads, not just as locks, and low-latency notification is a valuable property to have.
* fix build error on arm due to new a_spin codeRich Felker2014-08-251-1/+1
| | | | this was broken by commit ea818ea8340c13742a4f41e6077f732291aea4bc.
* sanitize number of spins in userspace before futex waitRich Felker2014-08-252-2/+2
| | | | | | | | | | | | | | | the previous spin limit of 10000 was utterly unreasonable. empirically, it could consume up to 200000 cycles, whereas a failed futex wait (EAGAIN) typically takes 1000 cycles or less, and even a true wait/wake round seems much less expensive. the new counts (100 for general wait, 200 in barrier) were simply chosen to be in the range of what's reasonable without having adverse effects on casual micro-benchmark tests I have been running. they may still be too high, from a standpoint of not wasting cpu cycles, but at least they're a lot better than before. rigorous testing across different archs and cpu models should be performed at some point to determine whether further adjustments should be made.
* add working a_spin() atomic for non-x86 targetsRich Felker2014-08-256-0/+6
| | | | | | | | | | | | | conceptually, a_spin needs to be at least a compiler barrier, so the compiler will not optimize out loops (and the load on each iteration) while spinning. it should also be a memory barrier, or the spinning thread might keep spinning without noticing stores from other threads, thus delaying for longer than it should. ideally, an optimal a_spin implementation that avoids unnecessary cache/memory contention should be chosen for each arch, but for now, the easiest thing is to perform a useless a_cas on the calling thread's stack.
* fix false ownership of stdio FILEs due to tid reuseRich Felker2014-08-236-2/+40
| | | | | | | | | | | | | this is analogous commit fffc5cda10e0c5c910b40f7be0d4fa4e15bb3f48 which fixed the corresponding issue for mutexes. the robust list can't be used here because the locks do not share a common layout with mutexes. at some point it may make sense to simply incorporate a mutex object into the FILE structure and use it, but that would be a much more invasive change, and it doesn't mesh well with the current design that uses a simpler code path for internal locking and pulls in the recursive-mutex-like code when the flockfile API is used explicitly.
* fix fallback checks for kernels without private futex supportRich Felker2014-08-225-5/+5
| | | | for unknown syscall commands, the kernel produces ENOSYS, not EINVAL.
* fix use of uninitialized memory with application-provided thread stacksRich Felker2014-08-221-0/+2
| | | | | | | | | | the subsequent code in pthread_create and the code which copies TLS initialization images to the new thread's TLS space assume that the memory provided to them is zero-initialized, which is true when it's obtained by pthread_create using mmap. however, when the caller provides a stack using pthread_attr_setstack, pthread_create cannot make any assumptions about the contents. simply zero-filling the relevant memory in this case is the simplest and safest fix.
* add max_align_t definition for C11 and C++11Rich Felker2014-08-2010-0/+21
| | | | | | | | | | | | | | | | | 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).
* further simplify and optimize new cond varRich Felker2014-08-181-29/+21
| | | | | | | | | | | | | | the main idea of the changes made is to have waiters wait directly on the "barrier" lock that was used to prevent them from making forward progress too early rather than first waiting on the atomic state value and then attempting to lock the barrier. in addition, adjustments to the mutex waiter count are optimized. previously, each waking waiter decremented the count (unless it was the first) then immediately incremented it again for the next waiter (unless it was the last). this was a roundabout was of achieving the equivalent of incrementing it once for the first waiter and decrementing it once for the last.
* simplify and improve new cond var implementationRich Felker2014-08-181-40/+22
| | | | | | | | | | | | | | | | | | | | previously, wake order could be unpredictable: if a waiter happened to leave its futex wait on the state early, e.g. due to EAGAIN while restarting after a signal handler, it could acquire the mutex out of turn. handling this required ugly O(n) list walking in the unwait function and accounting to remove waiters that already woke from the list. with the new changes, the "barrier" locks in each waiter node are only unlocked in turn. in addition to simplifying the code, this seems to improve performance slightly, probably by reducing the number of accesses threads make to each other's stacks. as an additional benefit, unrecoverable mutex re-locking errors (mainly ENOTRECOVERABLE for robust mutexes) no longer need to be handled with deadlock; they can be reported to the caller, since the unlocking sequence makes it unnecessary to rely on the mutex to synchronize access to the waiter list.
* redesign cond var implementation to fix multiple issuesRich Felker2014-08-176-93/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | the immediate issue that was reported by Jens Gustedt and needed to be fixed was corruption of the cv/mutex waiter states when switching to using a new mutex with the cv after all waiters were unblocked but before they finished returning from the wait function. self-synchronized destruction was also handled poorly and may have had race conditions. and the use of sequence numbers for waking waiters admitted a theoretical missed-wakeup if the sequence number wrapped through the full 32-bit space. the new implementation is largely documented in the comments in the source. the basic principle is to use linked lists initially attached to the cv object, but detachable on signal/broadcast, made up of nodes residing in automatic storage (stack) on the threads that are waiting. this eliminates the need for waiters to access the cv object after they are signaled, and allows us to limit wakeup to one waiter at a time during broadcasts even when futex requeue cannot be used. performance is also greatly improved, roughly double some tests. basically nothing is changed in the process-shared cond var case, where this implementation does not work, since processes do not have access to one another's local storage.
* fix possible failure-to-wake deadlock with robust mutexesRich Felker2014-08-171-1/+4
| | | | | | | | | | | | | | | | | | when the kernel is responsible for waking waiters on a robust mutex whose owner died, it does not have a waiters count available and must rely entirely on the waiter bit of the lock value. normally, this bit is only set by newly arriving waiters, so it will be clear if no new waiters arrived after the current owner obtained the lock, even if there are other waiters present. leaving it clear is desirable because it allows timed-lock operations to remove themselves as waiters and avoid causing unnecessary futex wake syscalls. however, for process-shared robust mutexes, we need to set the bit whenever there are existing waiters so that the kernel will know to wake them. for non-process-shared robust mutexes, the wake happens in userspace and can look at the waiters count, so the bit does not need to be set in the non-process-shared case.
* make pointers used in robust list volatileRich Felker2014-08-1713-20/+27
| | | | | | | | | | | | | | | | | | | | 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.
* fix robust mutex unrecoverable status, and related clean-upRich Felker2014-08-163-12/+4
| | | | | | | | | | | | | | | | | a robust mutex should not enter the unrecoverable status until it's unlocked without marking it consistent. previously, flag 8 in the type was used as an indication of unrecoverable, but only honored after successful locking; this resulted in a race window where the unrecoverable mutex could appear to a second thread as locked/busy again while the first thread was in the process of observing it as unrecoverable. now, flag 8 is used to mean that the mutex is in the process of being recovered, but not yet marked consistent. the flag only takes effect in pthread_mutex_unlock, where it causes the value 0x40000000 (owner dead flag, with old owner tid 0, an otherwise impossible state) to be stored in the lock. subsequent lock attempts will interpret this state as unrecoverable.
* fix false ownership of mutexes due to tid reuse, using robust listRich Felker2014-08-164-23/+26
| | | | | | | | | | | | | | | | | | | | | | | per the resolution of Austin Group issue 755, the POSIX requirement that ownership be enforced for recursive and error-checking mutexes does not allow a random new thread to acquire ownership of an orphaned mutex just because it happened to be assigned the same tid as the original owner that exited with the mutex locked. one possible fix for this issue would be to disallow the kernel thread to terminate when it exited with mutexes held, permanently reserving the tid against reuse. however, this does not solve the problem for process-shared mutexes where lifetime cannot be controlled, so it was not used. the alternate approach I've taken is to reuse the robust mutex system for non-robust recursive and error-checking mutexes. when a thread exits, the kernel (or the new userspace robust-list code added in commit b092f1c5fa9c048e12d002c7b972df5ecbe96d1d) will set the owner-died bit for these orphaned mutexes, but since the mutex-type is not robust, pthread_mutex_trylock will not allow a new owner to acquire them. instead, they remain in a state of being permanently locked, as desired.
* optimize locking against vm changes for mmap/munmapRich Felker2014-08-162-8/+7
| | | | | | | | | | the whole point of this locking is to prevent munmap, or mmap with MAP_FIXED, from deallocating virtual addresses, or changing the backing a given virtual address refers to, during certain race windows involving self-synchronized unmapping or destruction of pthread synchronization objects. there is no need for exclusion in the other direction, so it suffices to take the lock momentarily and release it before making the syscall, rather than holding it across the syscall.
* enable private futex for process-local robust mutexesRich Felker2014-08-163-1/+25
| | | | | | | | | | | | | | | | | | | | | | the kernel always uses non-private wake when walking the robust list when a thread or process exits, so it's not able to wake waiters listening with the private futex flag. this problem is solved by doing the equivalent in userspace as the last step of pthread_exit. care is taken to remove mutexes from the robust list before unlocking them so that the kernel will not attempt to access them again, possibly after another thread locks them. this removal code can treat the list as singly-linked, since no further code which would add or remove items is able to run at this point. moreover, the pending pointer is not needed since the mutexes being unlocked are all process-local; in the case of asynchronous process termination, they all cease to exist. since a process-local robust mutex cannot come into existence without a call to pthread_mutexattr_setrobust in the same process, the code for userspace robust list processing is put in that source file, and a weak alias to a dummy function is used to avoid pulling in this bloat as part of pthread_exit in static-linked programs.
* make futex operations use private-futex mode when possibleRich Felker2014-08-1523-66/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | private-futex uses the virtual address of the futex int directly as the hash key rather than requiring the kernel to resolve the address to an underlying backing for the mapping in which it lies. for certain usage patterns it improves performance significantly. in many places, the code using futex __wake and __wait operations was already passing a correct fixed zero or nonzero flag for the priv argument, so no change was needed at the site of the call, only in the __wake and __wait functions themselves. in other places, especially where the process-shared attribute for a synchronization object was not previously tracked, additional new code is needed. for mutexes, the only place to store the flag is in the type field, so additional bit masking logic is needed for accessing the type. for non-process-shared condition variable broadcasts, the futex requeue operation is unable to requeue from a private futex to a process-shared one in the mutex structure, so requeue is simply disabled in this case by waking all waiters. for robust mutexes, the kernel always performs a non-private wake when the owner dies. in order not to introduce a behavioral regression in non-process-shared robust mutexes (when the owning thread dies), they are simply forced to be treated as process-shared for now, giving correct behavior at the expense of performance. this can be fixed by adding explicit code to pthread_exit to do the right thing for non-shared robust mutexes in userspace rather than relying on the kernel to do it, and will be fixed in this way later. since not all supported kernels have private futex support, the new code detects EINVAL from the futex syscall and falls back to making the call without the private flag. no attempt to cache the result is made; caching it and using the cached value efficiently is somewhat difficult, and not worth the complexity when the benefits would be seen only on ancient kernels which have numerous other limitations and bugs anyway.
* fix #ifdef inside a macro argument list in __init_tls.cSzabolcs Nagy2014-08-131-4/+3
| | | | | C99 6.10.3p11 disallows such constructs so use an #ifdef outside of the argument list of __syscall
* fix CPU_EQUAL macro in sched.hSzabolcs Nagy2014-08-131-1/+1
|
* add inline isspace in ctype.h as an optimizationSzabolcs Nagy2014-08-133-9/+7
| | | | | | | | | | | | | | | | | | | | | isspace can be a bottleneck in a simple parser, inlining it gives slightly smaller and faster code src/locale/pleval.o already had this optimization, the size change for other libc functions for i386 is src/internal/intscan.o 2134 2118 -16 src/locale/dcngettext.o 1562 1552 -10 src/network/res_msend.o 1961 1940 -21 src/network/lookup_name.o 2627 2608 -19 src/network/getnameinfo.o 1814 1811 -3 src/network/lookup_serv.o 643 624 -19 src/stdio/vfscanf.o 2675 2663 -12 src/stdlib/atoll.o 117 107 -10 src/stdlib/atoi.o 95 91 -4 src/stdlib/atol.o 95 91 -4 src/time/strptime.o 1515 1503 -12 (TOTALS) 432451 432321 -130
* add dlerror message for static-linked dlsym failureRich Felker2014-08-081-0/+2
|
* fix dlerror when using dlopen with a static libcClément Vasseur2014-08-081-0/+2
| | | | | when the dynamic loader is disabled, dlopen fails correctly but dlerror did not return a human readable error string like it should have.
* make clearenv available with _BSD_SOURCEClément Vasseur2014-08-081-1/+1
| | | | | glibc declares clearenv under _BSD_SOURCE, some applications might depend on it being available this way.
* make endmntent function handle null argumentTimo Teräs2014-08-081-1/+1
| | | | | The function originates from SunOS 4.x in which the null argument is allowed. glibc also handles this case.
* release 1.1.4 v1.1.4Rich Felker2014-07-312-1/+36
|
* update notice on broken gcc versions in INSTALL fileRich Felker2014-07-311-2/+4
|
* update COPYRIGHT file to reflect new contributorsRich Felker2014-07-311-1/+5
|
* harden locale name handling and prevent slashes in LC_MESSAGESRich Felker2014-07-311-3/+3
| | | | | | | | | | | | | | | | | | | | the code which loads locale files was already rejecting locale names containing slashes. however, LC_MESSAGES records a locale name even if libc does not have a matching locale file, so that gettext or application code can use the recorded locale name for message translations to languages that libc does not support. this recorded name was not being checked for slashes, meaning that such code could potentially be tricked into directory traversal. in addition, since the value of a locale category is sometimes used as a pathname component by callers, the improved code rejects any value beginning with a dot. this prevents traversal to the parent directory via "..", use of the top-level locale directory via ".", and also avoids "hidden" directories as a side effect. finally, overly long locale names are now rejected (treated as an unrecognized name and thus as an alias for C.UTF-8) rather than being truncated.
* implement ffsl and ffsll functionsRich Felker2014-07-313-0/+16
| | | | | | per the resolution of Austin Group issue #617, these are accepted for XSI option in POSIX future and thus I'm treating them as standard functions.
* limit visibility of ffs function declaration to _XOPEN_SOURCERich Felker2014-07-311-0/+2
| | | | | per the standard, ffs is XSI shaded, whereas the other functions in this header are in the base.
* fix broken offset argument to the mmap2 syscall on or1kRich Felker2014-07-301-0/+2
| | | | | | for or1k, the kernel expects the offset passed to mmap2 in units of the 8k page size, not the standard unit of 4k used on most other archs.
* add framework for mmap2 syscall unit to vary by archRich Felker2014-07-302-2/+7
|
* provide PAGE_SIZE as a constant value of 8192 on or1kRich Felker2014-07-301-0/+1
| | | | | according to Stefan Kristiansson, or1k page size is not actually variable and the value of 8192 is part of the ABI.
* plural rule evaluator rewrite for dcngettextSzabolcs Nagy2014-07-301-128/+106
| | | | | | | | | | | | | | | | | | | | | | | using an operator precedence parser the code size became smaller and it is only slower by about %10 size of old vs new pleval.o on different archs: (with inlined isspace added to pleval.c for now) old: text data bss dec hex filename 828 0 0 828 33c pl.i386.o 1152 0 0 1152 480 pl.arm.o 1704 0 0 1704 6a8 pl.mips.o 1328 0 0 1328 530 pl.ppc.o 992 0 0 992 3e0 pl.x64.o new: text data bss dec hex filename 693 0 0 693 2b5 pl.i386.o 972 0 0 972 3cc pl.arm.o 1276 0 0 1276 4fc pl.mips.o 1087 0 0 1087 43f pl.ppc.o 846 0 0 846 34e pl.x64.o
* reimplement if_nameindex and getifaddrs using netlinkTimo Teräs2014-07-294-184/+411
| | | | | | | | | | | | | | the previous implementations had several deficiencies, the most severe of which was the inability to report unconfigured interfaces or interfaces without ipv4 addresses. among the options discussed for fixing this, using netlink turned out to be the one with the least cost and most additional advantages. other improvements include: if_nameindex now avoids duplicates in the list it produces, but still includes legacy-style interface aliases if any are in use. getifaddrs now reports hardware addresses and includes the scope_id for link-local ipv6 addresses in the resulting address.
* fix terminal control ioctl constants for shRich Felker2014-07-291-4/+8
| | | | | | | | | | | | this commit changes the names to match the kernel names, exposing under the normal names the "old" versions which work with a smaller termios structure compatible with the userspace structure, and renaming the "new" versions with "2" on the end like the kernel has. this fixes spurious warnings "Unsupported ioctl: cmd=0x802c542a" from qemu-sh4 and should be more correct anyway, since our userspace termios structure does not have meaningful information in the part which the kernel would be interpreting as speeds with the new ioctl.
* tweaks to plural rules evaluatorSzabolcs Nagy2014-07-291-54/+44
| | | | | const parsing, depth accounting and failure handling was changed a bit so the generated code is slightly smaller.
* harden dcngettext plural processingRich Felker2014-07-291-2/+3
| | | | | | | | | | while the __mo_lookup backend can verify that the translated message ends with a null terminator, is has no way to know nplurals and thus no way to verify that sufficiently many null terminators are present in the string to satisfy all plural forms. the code in dcngettext was already attempting to avoid reading past the end of the mo file mapping, but failed to do so because the strlen call itself could over-read. using strnlen instead allows us to avoid the problem.
* harden mo file processing for locale/translationsRich Felker2014-07-291-2/+6
| | | | | | | | | | | | rather than just checking that the start of the string lies within the mapping, also check that the nominal length remains within the mapping, and that the null terminator is present at the nominal length. this ensures that the caller, using the result as a C string, will not read past the end of the mapping. the nominal length is never exposed to the caller, but it's useful internally to find where the null terminator should be without having to restort to linear search via strnlen/memchr.
* implement non-default plural rules for ngettext translationsRich Felker2014-07-282-8/+243
| | | | | the new code in dcngettext was written by me, and the expression evaluator by Szabolcs Nagy (nsz).
* remove unused a_cas_l from or1k atomic.hRich Felker2014-07-271-5/+0
| | | | this follows the same logic as in the previous commit for other archs.
* clean up unused and inconsistent atomics in arch dirsRich Felker2014-07-278-100/+0
| | | | | | | | | | | the a_cas_l, a_swap_l, a_swap_p, and a_store_l operations were probably used a long time ago when only i386 and x86_64 were supported. as other archs were added, support for them was inconsistent, and they are obviously not in use at present. having them around potentially confuses readers working on new ports, and the type-punning hacks and inconsistent use of types in their definitions is not a style I wish to perpetuate in the source tree, so removing them seems appropriate.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-10-30 19:23:09 +0000