1. 30 3月, 2011 1 次提交
    • R
      major improvements to cancellation handling · bf619d82
      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.
      bf619d82
  2. 25 3月, 2011 1 次提交
    • R
      overhaul cancellation to fix resource leaks and dangerous behavior with signals · b470030f
      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...
      b470030f
  3. 13 3月, 2011 1 次提交
  4. 25 2月, 2011 1 次提交
    • R
      various changes in preparation for dynamic linking support · 41d51836
      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.
      41d51836
  5. 21 2月, 2011 1 次提交
    • R
      use an accessor function for __libc data pointer when compiled as PIC · d89c9e8a
      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.
      d89c9e8a
  6. 19 2月, 2011 1 次提交
    • R
      add pthread_atfork interface · e9417fff
      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.
      e9417fff
  7. 12 2月, 2011 1 次提交