Message ID | 50BE4E58.3020002@redhat.com |
---|---|
State | New |
Headers | show |
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
diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in index 43b14a0..cfddfed 100644 --- a/libgcc/Makefile.in +++ b/libgcc/Makefile.in @@ -917,7 +917,7 @@ libgcc-std.ver: $(srcdir)/libgcc-std.ver.in sed -e 's/__PFX__/$(LIBGCC_VER_GNU_PREFIX)/g' \ -e 's/__FIXPTPFX__/$(LIBGCC_VER_FIXEDPOINT_GNU_PREFIX)/g' < $< > $@ -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 @@ -925,7 +925,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 \