Re: Question on PowerPC setjmp/longjmp ABI

[Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>]

On Sat, Feb 17, 2001 at 12:58:07PM -0800, Geoff Keating wrote:
> > 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.

Yes, that would work well.  It's going to require that I spend this
weekend rubbing my hands in the gory details of symbol versioning, but
I knew that was unavoidable as soon as I found myself in this mess :)

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

Require a glibc to only be configured with altivec support on systems
where it exists.  This isn't optimal, of course; in my hat as a Debian
developer, I loathe it.  We can work something out, though, once the
ABI change has been figured out - the Linux kernel emulates user reads
of the PVR, if I recall correctly, for just this sort of circumstance. 
We'll have to waste the space in jmp_buf, obviously, but no big deal. 
We can offer --with-altivec, --without-altivec, --with-altivec=runtime
or some such; Debian can ship glibc configured --with-altivec=runtime.

Do you think such a patch would be acceptable?  I can try to work out
the details of it now, possibly barring the --with-altivec=runtime code.

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

Quite.  Hopefully I won't miss too many.

Dan

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