This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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: [PATCH] PPC libgcc compatibility


At 11:38 15.05.2002, Jakub Jelinek wrote:
>On Wed, May 15, 2002 at 10:33:19AM +0200, Franz Sirl wrote:
> > At 06:29 15.05.2002, Ulrich Drepper wrote:
> > >On Sun, 2002-05-12 at 14:07, Franz Sirl wrote:
> > >
> > > > the appended patch implements most of the libgcc routines that may 
> cause
> > > > broken binaries if a gcc-3.1 compiled glibc is installed. The symbols
> > > fixed
> > > > are (copied from gcc/libgcc2.c):
> > >
> > >The patch does not correspond to what is done for IA-64.  The functions
> > >should not be available for linking.  The madness must stop.  I've made
> > >some changes to your code which are completely untested.  Give the CVS
> > >trunk a try.
> >
> > If it's not linkable, that's fine with me, actually I even prefer that.
> > It's just that I started with divdi3.c as a template, which doesn't have
> > this symbol_version() stuff in it, should it?
>
>No, divdi3.c should not IMHO, since it is used by arches where this is a part
>of exported ABI (unlike IA-64 or PPC it has been that way from the
>beginning). I think PPC should use a .c wrapper around
>it and add symbol_version().

Ah, OK. Didn't know that.

>Some more notes about the patch: you include
>longlong.h and all its machinery everywhere, while none of the routines
>does actually use it. I think it would be way better to just use *int*_t
>types everywhere and get rid of the longlong.h stuff which is not needed
>at all. Also, when you're calling say in fixdfdi.c __fixunsdfdi, you should
>do so through INTUSE() and add __fixunsdfdi_internal prototype and
>INTDEF().

I'll check that out.

>Last the comments on top of the files were not changed from divdi3.

Uli fixed that on-the-fly :-).

Dumb question, it just occurred to me that there might be an even simpler 
solution here, why don't we just create a 
sysdeps/<platform>/libgcc-compat.c that pulls in all needed symbols from 
libgcc.a?

Like for example:

#include <stdint.h>
#include <shlib-compat.h>

#if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_2_6)


extern int64_t __fixdfdi (double);

int64_t INTUSE (__fixdfdi) (double d)
{
   return __fixdfdi (d);
}
symbol_version (INTUSE (__fixdfdi), __fixdfdi, GLIBC_2.0);


extern int64_t __fixunsdfdi (double);

int64_t INTUSE (__fixunsdfdi) (double d)
{
   return __fixunsdfdi (d);
}
symbol_version (INTUSE (__fixunsdfdi), __fixunsdfdi, GLIBC_2.0);

#endif


After all this is backwards compatibility code, so performance is no issue.

Franz.


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