Re: [PATCH] Memory fencing problem in pthread cancellation

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Jan 15, 2013 at 08:07:06PM +0000, Joseph S. Myers wrote:
> On Tue, 15 Jan 2013, Rich Felker wrote:
> 
> > On modern gcc, libgcc_s.so.1 is not even needed; support for
> > dl_iterate_phdr makes it so linking libgcc_eh.a into multiple DSOs
> > works fine even if unwinding crosses DSO boundaries. Thus, removing
> > the dynamic loading of libgcc_s.so.1 and just directly referencing the
> > unwind symbols should give the correct behavior regardless of which
> > sort of libgcc is being used. Personally, I would suggest building
> > libpthread.so with -static-libgcc so that the unwind support just gets
> > builting rather than loading an extra .so at program load time or at
> > runtime. This is by far the cleanest solution.
> 
> That seems even less likely to work well with bootstrapping, where the aim 
> is that glibc can be built with an initial bootstrap compiler and produce 
> identical installed binaries to those you get if you rebuild GCC then 
> glibc afterwards: parts of the unwind code in libgcc are disabled if libc 
> headers aren't available when libgcc is built.  Setting DT_NEEDED without 
> using GCC's libgcc_s.so.1 in the process at least has a chance of 
> producing stable libc binaries at the first iteration.  And what would 
> happen with an old unwinder linked statically into libpthread if a new 
> program built with newer GCC uses cancellation and has unwind info needing 
> a new unwinder from new libgcc?

This explicitly isn't allowed. The whole point of the modern unwind
design is that any unwinder can be used, and there can be more than
one copy of the unwind code in a single program. Anything else would
have all sorts of nasty issues.

> (The eventual aim would be that nothing apart from libgcc gets built more 
> than once in a bootstrap process, which nevertheless produces the same 
> binaries you get if you iterated GCC and glibc builds.  See 
> <http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>.)

I agree this is something to consider, but I think difficulty
bootstrapping is a much smaller issue than all programs using
pthreads/cancellation being subject to a mix (pick 2 or so) of memory
synchronization bugs, bad performance in pthread_cancel, and/or aborts
when pthread_cancel fails to load libgcc_s...

Rich