- 30 3月, 2011 1 次提交
-
-
由 Rich Felker 提交于
- there is no longer any risk of spoofing cancellation requests, since the cancel flag is set in pthread_cancel rather than in the signal handler. - cancellation signal is no longer unblocked when running the cancellation handlers. instead, pthread_create will cause any new threads created from a cancellation handler to unblock their own cancellation signal. - various tweaks in preparation for POSIX timer support.
-
- 25 3月, 2011 1 次提交
-
-
由 Rich Felker 提交于
this commit addresses two issues: 1. a race condition, whereby a cancellation request occurring after a syscall returned from kernelspace but before the subsequent CANCELPT_END would cause cancellable resource-allocating syscalls (like open) to leak resources. 2. signal handlers invoked while the thread was blocked at a cancellation point behaved as if asynchronous cancellation mode wer in effect, resulting in potentially dangerous state corruption if a cancellation request occurs. the glibc/nptl implementation of threads shares both of these issues. with this commit, both are fixed. however, cancellation points encountered in a signal handler will not be acted upon if the signal was received while the thread was already at a cancellation point. they will of course be acted upon after the signal handler returns, so in real-world usage where signal handlers quickly return, it should not be a problem. it's possible to solve this problem too by having sigaction() wrap all signal handlers with a function that uses a pthread_cleanup handler to catch cancellation, patch up the saved context, and return into the cancellable function that will catch and act upon the cancellation. however that would be a lot of complexity for minimal if any benefit...
-
- 13 3月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-
- 25 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
prefer using visibility=hidden for __libc internal data, rather than an accessor function, if the compiler has visibility. optimize with -O3 for PIC targets (shared library). without heavy inlining, reloading the GOT register in small functions kills performance. 20-30% size increase for a single libc.so is not a big deal, compared to comparaible size increase in every static binaries. use -Bsymbolic-functions, not -Bsymbolic. global variables are subject to COPY relocations, and thus binding their addresses in the library at link time will cause library functions to read the wrong (original) copies instead of the copies made in the main program's bss section. add entry point, _start, for dynamic linker.
-
- 21 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
prior to this change, a large portion of libc was unusable prior to relocation by the dynamic linker, due to dependence on the global data in the __libc structure and the need to obtain its address through the GOT. with this patch, the accessor function __libc_loc is now able to obtain the address of __libc via PC-relative addressing without using the GOT. this means the majority of libc functionality is now accessible right away. naturally, the above statements all depend on having an architecture where PC-relative addressing and jumps/calls are feasible, and a compiler that generates the appropriate code.
-
- 19 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
note that this presently does not handle consistency of the libc's own global state during forking. as per POSIX 2008, if the parent process was threaded, the child process may only call async-signal-safe functions until one of the exec-family functions is called, so the current behavior is believed to be conformant even if non-ideal. it may be improved at some later time.
-
- 12 2月, 2011 1 次提交
-
-
由 Rich Felker 提交于
-