This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Memory fencing problem in pthread cancellation
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
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.