- 04 6月, 2012 2 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
- 03 6月, 2012 8 次提交
-
-
由 Rich Felker 提交于
Per POSIX, "The abort() function shall cause abnormal process termination to occur, unless the signal SIGABRT is being caught and the signal handler does not return." If SIGABRT is blocked or if a signal handler is installed and does return, abort is still required to cause abnormal program termination. We cannot use a_crash() to do this, since a SIGILL handler could also be installed (and might even longjmp out of the abort, not expecting to be invoked from within abort), nor can we rely on resetting the signal handler and re-raising the signal (this has race conditions in multi-threaded programs). On the other hand, SIGKILL is a perfectly safe, unblockable way to obtain abnormal program termination, and it requires no ugly loop-and-retry logic.
-
由 Rich Felker 提交于
for some nonsensical reason, glibc's headers use inline functions that redirect some of the standard functions to ugly nonstandard names (and likewise for some of their nonstandard functions).
-
由 Rich Felker 提交于
I've been looking for data that would suggest a good default, and since little has shown up, i'm doing this based on the limited data I have. the value 80k is chosen to accommodate 64k of application data (which happens to be the size of the buffer in git that made it crash without a patch to call pthread_attr_setstacksize) plus the max stack usage of most libc functions (with a few exceptions like crypt, which will be fixed soon to avoid excessive stack usage, and [n]ftw, which inherently uses a fair bit in recursive directory searching). if further evidence emerges suggesting that the default should be larger, I'll consider changing it again, but I'd like to avoid it getting too large to avoid the issues of large commit charge and rapid address space exhaustion on 32-bit machines.
-
由 Rich Felker 提交于
this fix is necessary because a program could be started with some of the implementation-reserved signals masked (e.g. due to exec having been called from a signal handler, or from a non-musl program) and then could obtain an invalid-to-use-later sigset_t as the old/saved signal mask.
-
由 Rich Felker 提交于
this action is now performed in pthread_self initialization; it must be performed there in case the first call to pthread_create is from a signal handler, in which case the old signal mask could be restored on return from the signal.
-
由 Rich Felker 提交于
this should be the last major fix needed to support running glibc-linked conforming POSIX programs with musl in place of glibc, as long as musl provides the features they need and they don't use pthread cancellation (which is implemented as c++ exceptions in glibc, and fundamentally incompatible with musl).
-
由 Rich Felker 提交于
lots of broken programs expect this, and it's gotten to the point of being a troubleshooting FAQ topic. best to just fix it.
-
由 Rich Felker 提交于
this was fixed previously on i386 but the corresponding code on x86_64 was missed.
-
- 01 6月, 2012 2 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
these will NOT be used when compiling with -D_LARGEFILE64_SOURCE on musl; instead, they exist in the hopes of eventually being able to run some glibc-linked apps with musl sitting in place of glibc. also remove the (apparently incorrect) fcntl alias.
-
- 31 5月, 2012 1 次提交
-
-
由 Rich Felker 提交于
linking the wrong crt1.o resulted in textrels and thus crashing
-
- 29 5月, 2012 4 次提交
-
-
由 Rich Felker 提交于
no idea where I got the idea fpurge should exist...
-
由 Rich Felker 提交于
also fix up distinction of what is GNU-only and what's GNU+BSD
-
由 Rich Felker 提交于
-
由 nsz 提交于
-
- 28 5月, 2012 2 次提交
-
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
two actual issues: one is that __dynlink no longer wants/needs a GOT pointer argument, so the code to generate that argument can be removed. the other issue was that in the i386 code, argc/argv were being loaded into registers that would be call-clobbered, then copied to preserved registers, rather than just being loaded into the proper call-preserved registers to begin with. this cleanup is in preparation for adding new dynamic linker functionality (ability to explicitly invoke the dynamic linker to run a program).
-
- 27 5月, 2012 3 次提交
-
-
由 Rich Felker 提交于
bug report and solution by Richard Pennington
-
由 Rich Felker 提交于
issue reported by Richard Pennington; slightly simpler fix applied
-
由 Rich Felker 提交于
bug report and solution by Richard Pennington
-
- 26 5月, 2012 2 次提交
-
-
由 Rich Felker 提交于
unfortunately in dynamic-linked programs, these macros cause pthread_self to be initialized, which costs a couple syscalls, and (much worse) would necessarily fail, crash, and burn on ancient (2.4 and earlier) kernels where setting up a thread pointer does not work. i'd like to do this in a more generic way that avoids all use of cleanup push/pop before pthread_self has been successfully called and avoids ugly if/else constructs like the one in this commit, but for now, this will suffice.
-
由 Rich Felker 提交于
if the process started with these signals blocked, cancellation could fail or setxid could deadlock. there is no way to globally unblock them after threads have been created. by unblocking them in the pthread_self initialization for the main thread, we ensure that they're unblocked before any other threads are created and also outside of any signal handler context (sigaction initialized pthread_self), which is important so that return from a signal handler won't re-block them.
-
- 25 5月, 2012 5 次提交
-
-
由 Rich Felker 提交于
TRE has a broken assumption that wchar_t is signed, which is a sane expectation, but not required by the standard, and false on ARM's ABI. i leave tre_char_t as wchar_t for now, since a pointer to it is directly passed to functions that need pointer to wchar_t. it does not seem to break anything. and since the maximum unicode scalar value is 0x10ffff, just use that explicitly rather than using the max value of any particular C type.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
the bug was that cancellation requests which arrived while a cancellation point was interrupted by a signal handler would not be acted upon when the signal handler returns. this was because cp_sp was never set; it's no longer needed or used. instead, just always re-raise the signal when cancellation was not acted upon. this wastes a tiny amount of time in the rare case where it even matters, but it ensures correctness and simplifies the code.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
-
- 24 5月, 2012 4 次提交
-
-
由 Rich Felker 提交于
the old code could be kept for cases where SYS_utime is available, but it's not really worth the ifdef ugliness. and better to avoid deprecated stuff just in case the kernel devs ever get crazy enough to start removing it from archs where it was part of the ABI and breaking static bins...
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
stale state information indicating that a thread was possibly blocked at a cancellation point could get left behind if longjmp was used to exit a signal handler that interrupted a cancellation point. to fix the issue, we throw away the state information entirely and simply compare the saved instruction pointer to a range of code addresses in the __syscall_cp_asm function. all the ugly PIC work (which becomes minimal anyway with this approach) is defered to cancellation time instead of happening at every syscall, which should improve performance too. this commit also fixes cancellation on arm, which was mildly broken (race condition, not checking cancellation flag once inside the cancellation point zone). apparently i forgot to implement that. the new arm code is untested, but appears correct; i'll test and fix it later if there are problems.
-
由 Rich Felker 提交于
no need to pass unnecessary extra arguments on to the core code in pthread_create.c. this just wastes cycles and code bloat.
-
- 23 5月, 2012 7 次提交
-
-
由 Rich Felker 提交于
i originally made it the same size as the bloated GNU version, which contains space for saved signal mask, but this makes some structures containing jmp_buf become much larger for no benefit. we will never use the signal mask field with plain setjmp; sigsetjmp serves that purpose.
-
由 Rich Felker 提交于
i made a best attempt, but the intended semantics of this function are fundamentally contradictory. there is no consistent way to handle ownership of locks when forking a multi-threaded process. the code could have worked by accident for programs that only used normal mutexes and nothing else (since they don't actually store or care about their owner), but that's about it. broken-by-design interfaces that aren't even in glibc (only solaris) don't belong in musl.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
this is actually rather ugly, and would get even uglier if we ever want to support further feature test macros. at some point i may factor the bits headers into separate files for C base, POSIX base, and nonstandard extensions (the only distinctions that seem to matter now) and then the logic for which to include can go in the main header rather than being duplicated for each arch. the downside of this is that it would result in more files having to be opened during compilation, so as long as the ugliness does not grow, i'm inclined to leave it alone for now.
-
由 Rich Felker 提交于
-
由 Rich Felker 提交于
there is no reason to avoid multiple identical macro definitions; this is perfectly legal C, and even with the maximal warning options enabled, gcc does not issue any warning for it.
-
由 Rich Felker 提交于
its only purpose was for use on non-BSD systems that implement sysv semantics for signal() by default.
-