This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Question on PowerPC setjmp/longjmp ABI
- To: libc-alpha at sourceware dot cygnus dot com
- Subject: Question on PowerPC setjmp/longjmp ABI
- From: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Date: Sat, 17 Feb 2001 13:34:10 -0500
- Cc: Geoff Keating <geoffk at geoffk dot org>
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.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/