Re: [PATCH] Memory fencing problem in pthread cancellation

[Roland McGrath <roland at hack dot frob dot com>]

Someone like Jakub probably has a more reliable concrete explanation of the
rationale that applied at the time we started using demand-loaded libgcc_s.
I can think of two or three issues and imagine that I recall that these
were the ones actually of concern at the time.

1. There was a transitional issue where people might be using a GCC version
   (or configuration) that didn't install libgcc_s.so.1.  If pthread_cancel
   was never called, then they didn't hit the requirement so this avoided
   a hard dependency on a newer GCC installation to go with a libc upgrade.

2. Most programs (and most runs of most of the rest) don't use the unwind
   facilities.  Using DT_NEEDED would impose the costs in startup time,
   memory usage, address space use, etc. of loading another DSO when it was
   never needed.

3. The unwinder code has had bugs before and has also before had
   enhancements to support new format details added.  (The enhancement
   that I recall was the 'S' flag in augmentation, which is required by
   the x86-32 vDSO's unwind info for the signal trampoline.)  So it's
   important that new unwinder code can be deployed without relinking
   everything.  This certainly doesn't preclude using libgcc_s.so.1 via
   DT_NEEDED, but it does give the lie to the supposition that you could
   just statically link -lgcc_eh into every executable and DSO and be fine.


Thanks,
Roland