Patchwork Fix bootstrap/55571

My recent change to fix PR48076 broke arm-linux, and probably mips-linux,
where one must defer to the kernel in order to achieve a memory barrier
for the currently running cpu.

The __sync* family of functions was put into libgcc.a, and not into the
shared library, so that invocations of these functions would be fast and
not go through symbol resolution and the PLT.

My change ensures that libgcc_s.so.1, like any other library that would
be built, contains a copy of whatever symbols it requires from libgcc.a.
Since these functions are hidden, this does not change the exported ABI
of the shared library.

This does add 3K to the size of libgcc_s.so.  That could be reduced by
breaking up the arm linux-atomic.c file into per-function units.  Or we
just ignore the problem because 3K isn't worth worrying about.

Alternately, we could take this opportunity to adjust things so that
the symbols *are* exported from the shared library.  Obviously we cannot
do this on any of the release branches.  I'll leave that choice to the
ARM maintainers.

Tested on arm-linux-gnueabi, armv7l-unknown-linux-gnueabihf, and a
sanity check on x86_64-linux (wherein libgcc_s.so.1 is unchanged).


r~
PR bootstrap/55571
        * Makefile.in (libgcc_s.so): Depend on and link with libgcc.a.
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 7e2ab93..b57aeb6 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -795,7 +795,7 @@ libgcc_s$(SHLIB_EXT): libgcc.map
 mapfile = libgcc.map
 endif
 
-libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts)
+libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts) libgcc.a
 	# @multilib_flags@ is still needed because this may use
 	# $(GCC_FOR_TARGET) and $(LIBGCC2_CFLAGS) directly.
 	# @multilib_dir@ is not really necessary, but sometimes it has
@@ -803,7 +803,7 @@ libgcc_s$(SHLIB_EXT): $(libgcc-s-objects) $(extra-parts)
 	$(mkinstalldirs) $(MULTIDIR)
 	$(subst @multilib_flags@,$(CFLAGS) -B./,$(subst \
 		@multilib_dir@,$(MULTIDIR),$(subst \
-		@shlib_objs@,$(objects),$(subst \
+		@shlib_objs@,$(objects) libgcc.a,$(subst \
 		@shlib_base_name@,libgcc_s,$(subst \
 		@shlib_map_file@,$(mapfile),$(subst \
 		@shlib_slibdir_qual@,$(MULTIOSSUBDIR),$(subst \

Richard Henderson <rth@redhat.com> writes:
> My recent change to fix PR48076 broke arm-linux, and probably mips-linux,
> where one must defer to the kernel in order to achieve a memory barrier
> for the currently running cpu.
>
> The __sync* family of functions was put into libgcc.a, and not into the
> shared library, so that invocations of these functions would be fast and
> not go through symbol resolution and the PLT.
>
> My change ensures that libgcc_s.so.1, like any other library that would
> be built, contains a copy of whatever symbols it requires from libgcc.a.
> Since these functions are hidden, this does not change the exported ABI
> of the shared library.
>
> This does add 3K to the size of libgcc_s.so.  That could be reduced by
> breaking up the arm linux-atomic.c file into per-function units.  Or we
> just ignore the problem because 3K isn't worth worrying about.
>
> Alternately, we could take this opportunity to adjust things so that
> the symbols *are* exported from the shared library.  Obviously we cannot
> do this on any of the release branches.  I'll leave that choice to the
> ARM maintainers.

FWIW, the MIPS16 helper routines are tiny and each one is already
in a separate object, so I think this patch is what we want there
regardless of what we do for ARM.

Although I suppose it's academic, because there isn't yet a target
for building MIPS16 libgcc.sos out of the box.

Richard