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] | |
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] |