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]

Re: Question on PowerPC setjmp/longjmp ABI


> Date: Sat, 17 Feb 2001 13:34:10 -0500
> From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>

> I have some patches that I'm cleaning up for FPU-less powerpc support, and
> there was one thing I wanted to ask about before I submitted them.  For
> longjmp/setjmp, powerpc-*-linux follows the SysV ABI and saves both GPRs and
> FPRs.  Obviously, this isn't optimal if we don't have an FPU at all.
> 
> Now, what was originally doing was saving only the GPRs and miscellaneous
> registers, but not changing the definition of jmp_buf and friends.  It's not
> optimal, and it wastes space, but it's much more compatible.
> 
> I'd rather save the space, obviously.  And there's an associated problem -
> Altivec, which I'm also working on.  We'd like to have setjmp()/longjmp()
> save and restore vector state (according to Troy Benjegerdes, that means
> VRSAVE and v20-v31 - is this specified in any formal ABI?).  This means we
> have to change the size of jmp_buf.
> 
> Is it acceptable to change this ABI depending on how glibc is configured? 
> I'm also considering playing games with symbol versioning so that precompiled
> non-altivec-aware binaries (thus, with a smaller jmp_buf) will get a
> legitimate setjmp/longjmp as long as they don't pass a jmp_buf into a
> recompiled program.  Is there a problem with that?  How would I name the
> version, since it is not a glibc version change but a glibc configuration
> change?  I have the feeling that this isn't a good use of versioning, but I
> can't think of a better way.

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.

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.

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


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