Re: [PATCH] Memory fencing problem in pthread cancellation

[Rich Felker <dalias at aerifal dot cx>]

On Wed, Jan 16, 2013 at 02:13:57PM -0800, Roland McGrath wrote:
> 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.

Thanks for digging this up.

> 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.

These choices make some sense to me in the historical context of
needing libgcc_s, but now that -static-libgcc is viable, the pros and
cons seem to have shifted quite a bit. I think it's definitelt a
decision that merits reconsideration.

> 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.

Could you elaborate on this? It's partly just a matter of personal
curiosity for me, but I think it's relevant to the topic at hand too.
I've seen that the unwinder goes to great lengths (I would call it
"hideous hacks") for stuff related to signal trampolines, and as far
as I can tell, the only reason it would ever be needed is for
unwinding out of signal handlers, which is DEEP in the realm of UB and
not something I can see any justification for trying to support. Is
there another reason the signal trampolines need special consideration
that I'm not seeing?

Rich