This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Memory fencing problem in pthread cancellation
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?
(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>.)
--
Joseph S. Myers
joseph@codesourcery.com