about summary refs log tree commit diff
path: root/src/internal
Commit message (Collapse)AuthorAgeFilesLines
* don't inline __rem_pio2l so the code size is smallernsz2012-03-191-0/+1
|
* fix loads of missing const in new libm, and some global vars (?!) in powlRich Felker2012-03-181-2/+2
|
* fix namespace issues for lgamma, etc.Rich Felker2012-03-161-0/+2
| | | | standard functions cannot depend on nonstandard symbols
* first commit of the new libm!Rich Felker2012-03-132-0/+323
| | | | | | | | | | | | | | | | thanks to the hard work of Szabolcs Nagy (nsz), identifying the best (from correctness and license standpoint) implementations from freebsd and openbsd and cleaning them up! musl should now fully support c99 float and long double math functions, and has near-complete complex math support. tgmath should also work (fully on gcc-compatible compilers, and mostly on any c99 compiler). based largely on commit 0376d44a890fea261506f1fc63833e7a686dca19 from nsz's libm git repo, with some additions (dummy versions of a few missing long double complex functions, etc.) by me. various cleanups still need to be made, including re-adding (if they're correct) some asm functions that were dropped.
* fix obscure bug in strtoull reading the highest 16 possible valuesRich Felker2012-03-021-1/+1
|
* new attempt at working around the gcc 3 visibility bugRich Felker2012-02-242-0/+7
| | | | | since gcc is failing to generate the necessary ".hidden" directive in the output asm, generate it explicitly with an __asm__ statement...
* remove useless attribute visibility from definitionsRich Felker2012-02-241-1/+1
| | | | | | this was a failed attempt at working around the gcc 3 visibility bug affecting x86_64. subsequent patch will address it with an ugly but working hack.
* cleanup and work around visibility bug in gcc 3 that affects x86_64Rich Felker2012-02-232-6/+11
| | | | | | | | | | | | | | in gcc 3, the visibility attribute must be placed on both the declaration and on the definition. if it's omitted from the definition, the compiler fails to emit the ".hidden" directive in the assembly, and the linker will either generate textrels (if supported, such as on i386) or refuse to link (on targets where certain types of textrels are forbidden or impossible without further assumptions about memory layout, such as on x86_64). this patch also unifies the decision about when to use visibility into libc.h and makes the visibility in the utf-8 state machine tables based on libc.h rather than a duplicate test.
* synchronize cond var destruction with exiting waitsRich Felker2011-10-021-0/+1
|
* improve pshared barriersRich Felker2011-09-281-1/+1
| | | | | | | | | | | | | | eliminate the sequence number field and instead use the counter as the futex because of the way the lock is held, sequence numbers are completely useless, and this frees up a field in the barrier structure to be used as a waiter count for the count futex, which lets us avoid some syscalls in the best case. as of now, self-synchronized destruction and unmapping should be fully safe. before any thread can return from the barrier, all threads in the barrier have obtained the vm lock, and each holds a shared lock on the barrier. the barrier memory is not inspected after the shared lock count reaches 0, nor after the vm lock is released.
* process-shared barrier support, based on discussion with bdonlanRich Felker2011-09-271-3/+5
| | | | | | | | | | | | | this implementation is rather heavy-weight, but it's the first solution i've found that's actually correct. all waiters actually wait twice at the barrier so that they can synchronize exit, and they hold a "vm lock" that prevents changes to virtual memory mappings (and blocks pthread_barrier_destroy) until all waiters are finished inspecting the barrier. thus, it is safe for any thread to destroy and/or unmap the barrier's memory as soon as pthread_barrier_wait returns, without further synchronization.
* fix lost signals in cond varsRich Felker2011-09-261-0/+1
| | | | | | | | | | | due to moving waiters from the cond var to the mutex in bcast, these waiters upon wakeup would steal slots in the count from newer waiters that had not yet been signaled, preventing the signal function from taking any action. to solve the problem, we simply use two separate waiter counts, and so that the original "total" waiters count is undisturbed by broadcast and still available for signal.
* cleanup various minor issues reported by nszRich Felker2011-09-261-3/+3
| | | | | | | | | the changes to syscall_ret are mostly no-ops in the generated code, just cleanup of type issues and removal of some implementation-defined behavior. the one exception is the change in the comparison value, which is fixed so that 0xf...f000 (which in principle could be a valid return value for mmap, although probably never in reality) is not treated as an error return.
* redo cond vars again, use sequence numbersRich Felker2011-09-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | testing revealed that the old implementation, while correct, was giving way too many spurious wakeups due to races changing the value of the condition futex. in a test program with 5 threads receiving broadcast signals, the number of returns from pthread_cond_wait was roughly 3 times what it should have been (2 spurious wakeups for every legitimate wakeup). moreover, the magnitude of this effect seems to grow with the number of threads. the old implementation may also have had some nasty race conditions with reuse of the cond var with a new mutex. the new implementation is based on incrementing a sequence number with each signal event. this sequence number has nothing to do with the number of threads intended to be woken; it's only used to provide a value for the futex wait to avoid deadlock. in theory there is a danger of race conditions due to the value wrapping around after 2^32 signals. it would be nice to eliminate that, if there's a way. testing showed no spurious wakeups (though they are of course possible) with the new implementation, as well as slightly improved performance.
* new futex-requeue-based pthread_cond_broadcast implementationRich Felker2011-09-251-3/+6
| | | | | | this avoids the "stampede effect" where pthread_cond_broadcast would result in all waiters waking up simultaneously, only to immediately contend for the mutex and go back to sleep.
* fix deadlock in condition wait whenever there are multiple waitersRich Felker2011-09-221-0/+1
| | | | | it's amazing none of the conformance tests i've run even bothered to check whether something so basic works...
* initial commit of the arm portRich Felker2011-09-181-0/+15
| | | | | | | | | | | | | this port assumes eabi calling conventions, eabi linux syscall convention, and presence of the kernel helpers at 0xffff0f?0 needed for threads support. otherwise it makes very few assumptions, and the code should work even on armv4 without thumb support, as well as on systems with thumb interworking. the bits headers declare this a little endian system, but as far as i can tell the code should work equally well on big endian. some small details are probably broken; so far, testing has been limited to qemu/aboriginal linux.
* overhaul clone syscall wrappingRich Felker2011-09-181-2/+1
| | | | | | | | | | | | | | | | | | | | several things are changed. first, i have removed the old __uniclone function signature and replaced it with the "standard" linux __clone/clone signature. this was necessary to expose clone to applications anyway, and it makes it easier to port __clone to new archs, since it's now testable independently of pthread_create. secondly, i have removed all references to the ugly ldt descriptor structure (i386 only) from the c code and pthread structure. in places where it is needed, it is now created on the stack just when it's needed, in assembly code. thus, the i386 __clone function takes the desired thread pointer as its argument, rather than an ldt descriptor pointer, just like on all other sane archs. this should not affect applications since there is really no way an application can use clone with threads/tls in a way that doesn't horribly conflict with and clobber the underlying implementation's use. applications are expected to use clone only for creating actual processes, possibly with new namespace features and whatnot.
* security hardening: ensure suid programs have valid stdin/out/errRich Felker2011-08-231-2/+4
| | | | | | | | | | | this behavior (opening fds 0-2 for a suid program) is explicitly allowed (but not required) by POSIX to protect badly-written suid programs from clobbering files they later open. this commit does add some cost in startup code, but the availability of auxv and the security flag will be useful elsewhere in the future. in particular auxv is needed for static-linked vdso support, which is still waiting to be committed (sorry nik!)
* pthread and synccall cleanup, new __synccall_wait opRich Felker2011-08-122-0/+2
| | | | | | | | | fix up clone signature to match the actual behavior. the new __syncall_wait function allows a __synccall callback to wait for other threads to continue without returning, so that it can resume action after the caller finishes. this interface could be made significantly more general/powerful with minimal effort, but i'll wait to do that until it's actually useful for something.
* simplify multi-threaded errno, eliminate useless function pointerRich Felker2011-08-061-2/+1
|
* use weak aliases rather than function pointers to simplify some codeRich Felker2011-08-061-2/+0
|
* overhaul rwlocks to address several issuesRich Felker2011-08-031-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | like mutexes and semaphores, rwlocks suffered from a race condition where the unlock operation could access the lock memory after another thread successfully obtained the lock (and possibly destroyed or unmapped the object). this has been fixed in the same way it was fixed for other lock types. in addition, the previous implementation favored writers over readers. in the absence of other considerations, that is the best behavior for rwlocks, and posix explicitly allows it. however posix also requires read locks to be recursive. if writers are favored, any attempt to obtain a read lock while a writer is waiting for the lock will fail, causing "recursive" read locks to deadlock. this can be avoided by keeping track of which threads already hold read locks, but doing so requires unbounded memory usage, and there must be a fallback case that favors readers in case memory allocation failed. and all of this must be synchronized. the cost, complexity, and risk of errors in getting it right is too great, so we simply favor readers. tracking of the owner of write locks has been removed, as it was not useful for anything. it could allow deadlock detection, but it's not clear to me that returning EDEADLK (which a buggy program is likely to ignore) is better than deadlocking; at least the latter behavior prevents further data corruption. a correct program cannot invoke this situation anyway. the reader count and write lock state, as well as the "last minute" waiter flag have all been combined into a single atomic lock. this means all state transitions for the lock are atomic compare-and-swap operations. this makes establishing correctness much easier and may improve performance. finally, some code duplication has been cleaned up. more is called for, especially the standard __timedwait idiom repeated in all locks.
* unify and overhaul timed futex waitsRich Felker2011-08-022-2/+4
| | | | | | | | | | | | | | new features: - FUTEX_WAIT_BITSET op will be used for timed waits if available. this saves a call to clock_gettime. - error checking for the timespec struct is now inside __timedwait so it doesn't need to be duplicated everywhere. cond_timedwait still needs to duplicate it to avoid unlocking the mutex, though. - pushing and popping the cancellation handler is delegated to __timedwait, and cancellable/non-cancellable waits are unified.
* add proper fuxed-based locking for stdioRich Felker2011-07-303-6/+8
| | | | | | | | | | | | | | | | | | | | | | previously, stdio used spinlocks, which would be unacceptable if we ever add support for thread priorities, and which yielded pathologically bad performance if an application attempted to use flockfile on a key file as a major/primary locking mechanism. i had held off on making this change for fear that it would hurt performance in the non-threaded case, but actually support for recursive locking had already inflicted that cost. by having the internal locking functions store a flag indicating whether they need to perform unlocking, rather than using the actual recursive lock counter, i was able to combine the conditionals at unlock time, eliminating any additional cost, and also avoid a nasty corner case where a huge number of calls to ftrylockfile could cause deadlock later at the point of internal locking. this commit also fixes some issues with usage of pthread_self conflicting with __attribute__((const)) which resulted in crashes with some compiler versions/optimizations, mainly in flockfile prior to pthread_create.
* new attempt at making set*id() safe and robustRich Felker2011-07-292-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changing credentials in a multi-threaded program is extremely difficult on linux because it requires synchronizing the change between all threads, which have their own thread-local credentials on the kernel side. this is further complicated by the fact that changing the real uid can fail due to exceeding RLIMIT_NPROC, making it possible that the syscall will succeed in some threads but fail in others. the old __rsyscall approach being replaced was robust in that it would report failure if any one thread failed, but in this case, the program would be left in an inconsistent state where individual threads might have different uid. (this was not as bad as glibc, which would sometimes even fail to report the failure entirely!) the new approach being committed refuses to change real user id when it cannot temporarily set the rlimit to infinity. this is completely POSIX conformant since POSIX does not require an implementation to allow real-user-id changes for non-privileged processes whatsoever. still, setting the real uid can fail due to memory allocation in the kernel, but this can only happen if there is not already a cached object for the target user. thus, we forcibly serialize the syscalls attempts, and fail the entire operation on the first failure. this *should* lead to an all-or-nothing success/failure result, but it's still fragile and highly dependent on kernel developers not breaking things worse than they're already broken. ideally linux will eventually add a CLONE_USERCRED flag that would give POSIX conformant credential changes without any hacks from userspace, and all of this code would become redundant and could be removed ~10 years down the line when everyone has abandoned the old broken kernels. i'm not holding my breath...
* comment non-obvious de bruijn sequence code in int parserRich Felker2011-07-251-0/+2
|
* fix various bugs in new integer parser frameworkRich Felker2011-07-141-4/+7
| | | | | | | | | | 1. my interpretation of subject sequence definition was wrong. adjust parser to conform to the standard. 2. some code for handling tail overflow case was missing (forgot to finish writing it). 3. typo (= instead of ==) caused ERANGE to wrongly behave like EINVAL
* new restartable integer parsing framework.Rich Felker2011-07-142-0/+116
| | | | | | | | | this fixes a number of bugs in integer parsing due to lazy haphazard wrapping, as well as some misinterpretations of the standard. the new parser is able to work character-at-a-time or on whole strings, making it easy to support the wide functions without unbounded space for conversion. it will also be possible to update scanf to use the new parser.
* restore use of .type in asm, but use modern @function (vs %function)Rich Felker2011-06-142-0/+2
| | | | | | | | this seems to be necessary to make the linker accept the functions in a shared library (perhaps to generate PLT entries?) strictly speaking libc-internal asm should not need it. i might clean that up later.
* fix race condition in pthread_killRich Felker2011-06-141-0/+1
| | | | | | | | | | | | | | if thread id was reused by the kernel between the time pthread_kill read it from the userspace pthread_t object and the time of the tgkill syscall, a signal could be sent to the wrong thread. the tgkill syscall was supposed to prevent this race (versus the old tkill syscall) but it can't; it can only help in the case where the tid is reused in a different process, but not when the tid is reused in the same process. the only solution i can see is an extra lock to prevent threads from exiting while another thread is trying to pthread_kill them. it should be very very cheap in the non-contended case.
* fix sigset macro for 64-bit systems (<< was overflowing due to wrong type)Rich Felker2011-06-131-1/+1
|
* remove all .size and .type directives for functions from the asmRich Felker2011-06-132-4/+0
| | | | | these are useless and have caused problems for users trying to build with non-gnu tools like tcc's assembler.
* implement uselocale function (minimal)Rich Felker2011-05-301-0/+2
|
* optimize compound-literal sigset_t's not to contain useless hurd bitsRich Felker2011-05-071-2/+4
|
* overhaul implementation-internal signal protectionsRich Felker2011-05-071-3/+6
| | | | | | | | | | | | | | | | | | | the new approach relies on the fact that the only ways to create sigset_t objects without invoking UB are to use the sig*set() functions, or from the masks returned by sigprocmask, sigaction, etc. or in the ucontext_t argument to a signal handler. thus, as long as sigfillset and sigaddset avoid adding the "protected" signals, there is no way the application will ever obtain a sigset_t including these bits, and thus no need to add the overhead of checking/clearing them when sigprocmask or sigaction is called. note that the old code actually *failed* to remove the bits from sa_mask when sigaction was called. the new implementations are also significantly smaller, simpler, and faster due to ignoring the useless "GNU HURD signals" 65-1024, which are not used and, if there's any sanity in the world, never will be used.
* completely new barrier implementation, addressing major correctness issuesRich Felker2011-05-061-4/+4
| | | | | | | | | | | | | | | | | | | | the previous implementation had at least 2 problems: 1. the case where additional threads reached the barrier before the first wave was finished leaving the barrier was untested and seemed not to be working. 2. threads leaving the barrier continued to access memory within the barrier object after other threads had successfully returned from pthread_barrier_wait. this could lead to memory corruption or crashes if the barrier object had automatic storage in one of the waiting threads and went out of scope before all threads finished returning, or if one thread unmapped the memory in which the barrier object lived. the new implementation avoids both problems by making the barrier state essentially local to the first thread which enters the barrier wait, and forces that thread to be the last to return.
* workaround for preprocessor bug in pccRich Felker2011-05-011-7/+7
| | | | | | | with this patch, musl compiles and mostly works with pcc 1.0.0. a few tests are still failing and i'm uncertain whether they are due to portability problems in musl, or bugs in pcc, but i suspect the latter.
* fix minor bugs due to incorrect threaded-predicate semanticsRich Felker2011-04-201-0/+1
| | | | | | | | | | | | some functions that should have been testing whether pthread_self() had been called and initialized the thread pointer were instead testing whether pthread_create() had been called and actually made the program "threaded". while it's unlikely any mismatch would occur in real-world problems, this could have introduced subtle bugs. now, we store the address of the main thread's thread descriptor in the libc structure and use its presence as a flag that the thread register is initialized. note that after fork, the calling thread (not necessarily the original main thread) is the new main thread.
* clean up handling of thread/nothread mode, lockingRich Felker2011-04-172-5/+4
|
* optimize cancellation enable/disable codeRich Felker2011-04-171-0/+1
| | | | | | | | | | | | | | | | | | the goal is to be able to use pthread_setcancelstate internally in the implementation, whenever a function might want to use functions which are cancellation points but avoid becoming a cancellation point itself. i could have just used a separate internal function for temporarily inhibiting cancellation, but the solution in this commit is better because (1) it's one less implementation-specific detail in functions that need to use it, and (2) application code can also get the same benefit. previously, pthread_setcancelstate dependend on pthread_self, which would pull in unwanted thread setup overhead for non-threaded programs. now, it temporarily stores the state in the global libc struct if threads have not been initialized, and later moves it if needed. this way we can instead use __pthread_self, which has no dependencies and assumes that the thread register is already valid.
* overhaul pthread cancellationRich Felker2011-04-173-8/+18
| | | | | | | | | | | | | | | | | | | | | | this patch improves the correctness, simplicity, and size of cancellation-related code. modulo any small errors, it should now be completely conformant, safe, and resource-leak free. the notion of entering and exiting cancellation-point context has been completely eliminated and replaced with alternative syscall assembly code for cancellable syscalls. the assembly is responsible for setting up execution context information (stack pointer and address of the syscall instruction) which the cancellation signal handler can use to determine whether the interrupted code was in a cancellable state. these changes eliminate race conditions in the previous generation of cancellation handling code (whereby a cancellation request received just prior to the syscall would not be processed, leaving the syscall to block, potentially indefinitely), and remedy an issue where non-cancellable syscalls made from signal handlers became cancellable if the signal handler interrupted a cancellation point. x86_64 asm is untested and may need a second try to get it right.
* use a separate signal from SIGCANCEL for SIGEV_THREAD timersRich Felker2011-04-141-0/+1
| | | | | | otherwise we cannot support an application's desire to use asynchronous cancellation within the callback function. this change also slightly debloats pthread_create.c.
* greatly improve SIGEV_THREAD timersRich Felker2011-04-091-0/+1
| | | | | calling pthread_exit from, or pthread_cancel on, the timer callback thread will no longer destroy the timer.
* move rsyscall out of pthread_create moduleRich Felker2011-04-062-1/+5
| | | | | | | | | | | | | | this is something of a tradeoff, as now set*id() functions, rather than pthread_create, are what pull in the code overhead for dealing with linux's refusal to implement proper POSIX thread-vs-process semantics. my motivations are: 1. it's cleaner this way, especially cleaner to optimize out the rsyscall locking overhead from pthread_create when it's not needed. 2. it's expected that only a tiny number of core system programs will ever use set*id() functions, whereas many programs may want to use threads, and making thread overhead tiny is an incentive for "light" programs to try threads.
* new framework to inhibit thread cancellation when neededRich Felker2011-04-051-0/+2
| | | | | | | with these small changes, libc functions which need to call functions which are cancellation points, but which themselves must not be cancellation points, can use the CANCELPT_INHIBIT and CANCELPT_RESUME macros to temporarily inhibit all cancellation.
* simplify calling of timer signal handlerRich Felker2011-04-031-2/+1
|
* simplify pthread tsd key handlingRich Felker2011-04-031-2/+1
|
* reorganize the __libc structure for threaded performance issuesRich Felker2011-04-011-6/+6
| | | | | | | we want to keep atomically updated fields (locks and thread count) and really anything writable far away from frequently-needed function pointers. stuff some rarely-needed function pointers in between to pad, hopefully up to a cache line boundary.
* optimize timer creation and possibly protect against some minor racesRich Felker2011-03-301-2/+0
| | | | | | | | | the major idea of this patch is not to depend on having the timer pointer delivered to the signal handler, and instead use the thread pointer to get the callback function address and argument. this way, the parent thread can make the timer_create syscall while the child thread is starting, and it should never have to block waiting for the barrier.