[3.2] HELP! How can I move libgcc_s symbols from version GLIBC_2.0 to GCC_3.0 keeping backwards compatibility?

[Franz Sirl]

On Freitag, 2. August 2002 01:21, Jakub Jelinek wrote:
> On Fri, Aug 02, 2002 at 12:57:19AM +0200, Franz Sirl wrote:
> > On Freitag, 2. August 2002 00:34, Jakub Jelinek wrote:
> > > On Fri, Aug 02, 2002 at 12:27:15AM +0200, Franz Sirl wrote:
> > > > Hi,
> > > >
> > > > I'm lost in symbol versioning. Currently due to a mistake on
> > > > powerpc-linux-gnu the 4 symbols __[u]divdi3 and __[u]moddi3 are
> > > > versioned as GLIBC_2.0 instead of GCC_3.0. I tried to fix it with an
> > > > corrected libgcc-glibc.ver version script and a small assembler
> > > > source. I able to get both __divdi3@GCC_3.0 and __divdi3@GLIBC_2.0,
> > > > but I want GCC_3.0 as a default version __divdi3@@GCC_3.0. How can I
> > > > accomplish that?
> > >
> > > See what e.g. s390 does. You certainly don't
> > > need any small assembler source, just cannot use the "generic" linux
> > > libgcc-glibc.ver, which means using something like:
> > > SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver
> > > $(srcdir)/config/rs6000/libgcc-glibc.ver in your
> > > config/rs6000/t-linux*.
> >
> > Yeah, that gives me __divdi3@@GCC_3.0, but what about a runtime
> > __divdi3@GLIBC_2.0 to maintain compatibility with a 3.0/3.1 shared
> > libgcc? Don't I need that too?
>
> See
> http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00705.html
> for my attempt to do that, but note that in the end IA-64 uses @@GLIBC_2.0
> symbols.

Hmm, that's essentially the same direction I was thinking of (see the appended 
patch), but I simply can't get both @@GCC_3.0 and @GLIBC_2.0 with GLOBAL 
scope. One of them always stays at LOCAL:

[fsirl@entropy:~/obj/gcc32/gcc]$ readelf -a libgcc_s.so|grep _divdi3
    41: 0000262c   220 FUNC    GLOBAL DEFAULT   10 __divdi3@@GCC_3.0
   348: 00006908     4 FUNC    LOCAL  DEFAULT   10 __divdi3_v_glibc20
   360: 00006908     4 FUNC    LOCAL  DEFAULT   10 __divdi3@GLIBC_2.0
   393: 0000262c   220 FUNC    GLOBAL DEFAULT   10 __divdi3

If I manually add __divdi3 to libgcc/libgcc.map (so it's listed under both 
GCC_3.0 and GLIBC_2.0) and relink libgcc_s.so, I get:

[fsirl@entropy:~/obj/gcc32/gcc]$ readelf -a libgcc_s.so|grep _divdi3
   119: 00006908     4 FUNC    GLOBAL DEFAULT   10 __divdi3@GLIBC_2.0
   246: 0000262c   220 FUNC    LOCAL  DEFAULT   10 __divdi3
   349: 00006908     4 FUNC    LOCAL  DEFAULT   10 __divdi3_v_glibc20
   471: 00006908     4 FUNC    GLOBAL DEFAULT   10 __divdi3@GLIBC_2.0

:-(.

The only method I found so far is to add a

	asm(".symver __divdi3,__divdi3@@@GCC_3.0");

directly to libgcc2.c.

I don't get it, I feel dumb, shouldn't the listing in libgcc.map version 
script globalize matching symbols? Why doesn't this happen with 
__divdi3@GLIBC_2.0?

Puzzled,
Franz.
-------------- next part --------------
Index: t-ppccomm
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/config/rs6000/t-ppccomm,v
retrieving revision 1.15
diff -u -p -r1.15 t-ppccomm
--- t-ppccomm	19 Feb 2002 19:40:41 -0000	1.15
+++ t-ppccomm	2 Aug 2002 22:59:16 -0000
@@ -1,10 +1,14 @@
 # Common support for PowerPC ELF targets (both EABI and SVR4).
 
-LIB2FUNCS_EXTRA = tramp.S
+LIB2FUNCS_EXTRA = tramp.S vers.S
 
 # This one can't end up in shared libgcc
 LIB2FUNCS_STATIC_EXTRA = eabi.S
 
+# Override t-slibgcc-elf-ver to export some libgcc symbols with
+# the symbol versions that glibc used.
+SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver $(srcdir)/config/rs6000/libgcc-glibc.ver
+
 # We want fine grained libraries, so use the new code to build the
 # floating point emulation libraries.
 FPBIT = fp-bit.c
@@ -23,6 +27,9 @@ eabi.S: $(srcdir)/config/rs6000/eabi.asm
 
 tramp.S: $(srcdir)/config/rs6000/tramp.asm
 	cat $(srcdir)/config/rs6000/tramp.asm > tramp.S
+
+vers.S: $(srcdir)/config/rs6000/vers.asm
+	cat $(srcdir)/config/rs6000/vers.asm > vers.S
 
 # Switch synonyms
 MULTILIB_MATCHES_FLOAT	= msoft-float=mcpu?401 \
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ libgcc-glibc.ver	Fri Aug  2 15:41:44 2002
@@ -0,0 +1,19 @@
+# In order to work around the very problems that force us to now generally
+# create a libgcc.so, glibc reexported a number of routines from libgcc.a.
+# By now choosing the same version tags for these specific routines, we
+# maintain enough binary compatibility to allow future versions of glibc
+# to defer implementation of these routines to libgcc.so via DT_AUXILIARY.
+
+%inherit GCC_3.0 GLIBC_2.0
+
+GLIBC_2.0 {
+  #__divdi3
+  # Exception handling support functions used by most everyone.
+  __register_frame
+  __register_frame_table
+  __deregister_frame
+  __register_frame_info
+  __deregister_frame_info
+  __frame_state_for
+  __register_frame_info_table
+}
--- /dev/null	Thu Oct  4 06:30:44 2001
+++ vers.asm	Fri Aug  2 16:01:52 2002
@@ -0,0 +1,37 @@
+	.file	"vers.asm"
+	.section	".text"
+
+	.align	2
+	.globl __divdi3_v_glibc20
+	.type	__divdi3_v_glibc20,@function
+__divdi3_v_glibc20:
+	b	__divdi3@local
+.Lfe1:
+	.size	__divdi3_v_glibc20,.Lfe1-__divdi3_v_glibc20
+
+	.globl __udivdi3_v_glibc20
+	.type	__udivdi3_v_glibc20,@function
+__udivdi3_v_glibc20:
+	b	__udivdi3@local
+.Lfe2:
+	.size	__udivdi3_v_glibc20,.Lfe2-__udivdi3_v_glibc20
+
+	.globl __moddi3_v_glibc20
+	.type	__moddi3_v_glibc20,@function
+__moddi3_v_glibc20:
+	b	__moddi3@local
+.Lfe3:
+	.size	__moddi3_v_glibc20,.Lfe3-__moddi3_v_glibc20
+
+	.globl __umoddi3_v_glibc20
+	.type	__umoddi3_v_glibc20,@function
+__umoddi3_v_glibc20:
+	b	__umoddi3@local
+.Lfe4:
+	.size	__umoddi3_v_glibc20,.Lfe4-__umoddi3_v_glibc20
+
+	.symver	__divdi3_v_glibc20,__divdi3@GLIBC_2.0
+	.symver	__udivdi3_v_glibc20,__udivdi3@GLIBC_2.0
+	.symver	__moddi3_v_glibc20,__moddi3@GLIBC_2.0
+	.symver	__umoddi3_v_glibc20,__umoddi3@GLIBC_2.0
+