This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

Attachment: gcc-libgcc-compat.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]