Re: Question on PowerPC setjmp/longjmp ABI

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot 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.

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

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.

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?

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/