Re: Question on PowerPC setjmp/longjmp ABI

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Sat, 17 Feb 2001 15:39:16 -0500
> From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>

> On Sat, Feb 17, 2001 at 12:03:37PM -0800, Geoff Keating wrote:
> > If the ABI is already different (eg. between regular and soft-float),
> > changing it more is OK, so yes, it's fine to shrink the jmp_buf
> > structure.
> 
> Ahh, right.  This makes sense; there's already a whole bunch of
> functions we don't provide in a soft-float library.

More to the point, the ABI for things like printf() is different, as
one version expects a "%g" to be in a FPR and the other one doesn't.

> > Altivec is a different problem, because Altivec doesn't introduce a
> > new ABI---you can link non-altivec code with altivec code, and this
> > should work just fine.  I think what we'll have to do is increase the
> > size of __jmp_buf, and version everything connected to it.
> > 
> > There've been a number of suggestions of things like this, that
> > involve tweaking the ABI.  I've been trying to keep a list so that if
> > we decide to do a big bang we can do them all at once.  At present,
> > the list includes:
> > 
> > * long double == 128 bits
> > * return small structures in registers
> > * add altivec support to setjmp/longjmp
> > 
> > I think we can do all these profitably using symbol versioning for
> > glibc, but they'll have significant impacts on other shared libraries,
> > some of whose authors won't want to deal with it and will just step
> > the version number.
> 
> I don't suppose you have a timeframe on this?  I guess, from looking at
> that list, that this'll require synchronous work in gcc and glibc.

There is some gcc work involved, but not much, and there's much more
glibc work.

> Unfortunately, I need to have an altivec-happy glibc for some customers
> as soon as possible; I'm trying very hard not to dig myself into a hole
> that I won't be able to climb back out of WRT compatibility.  My
> current plan is to introduce a dummy version for setjmp/longjmp,
> allowing old binaries to continue to run, and forcing a recompile of
> user code when we find a "correct" solution.  I'd rather avoid doing
> that if possible.

My suggestion is to have this code in mainline glibc, but not have it
the default.  In your glibc, make it the default.  This way all kinds
of code will run under all kinds of glibc, but the mainline glibc
doesn't impose an ABI change until we can do it all at once.

What do you plan to do to have glibc still work on systems where
there's no altivec support?

> I've also got the feeling that I'll make a horrible mess trying to
> version "everything associated with __jmp_buf".  For instance,
> I just noticed linuxthreads/ptlongjmp.c, which obviously also exposes
> jmp_buf to the application.  I'd need to add a matching version to
> libpthread, right?

Of course.  There are a number of places in glibc where jmp_buf is
visible externally, all the routines that operate on these need to be
versioned.  Look at it this way, it's not nearly as bad as the list of
places where the structure of 'long double' matters :-).

-- 
- Geoffrey Keating <geoffk@geoffk.org>