This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC,PATCH] Remove mode(word) - approach 1
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: bergner at vnet dot ibm dot com (Peter Bergner)
- Cc: Andreas dot Krebbel at de dot ibm dot com (Andreas Krebbel), iant at google dot com (Ian Lance Taylor), gcc-patches at gcc dot gnu dot org
- Date: Thu, 12 Apr 2007 21:32:30 +0200 (CEST)
- Subject: Re: [RFC,PATCH] Remove mode(word) - approach 1
Peter Bergner wrote:
> "Ulrich Weigand" <uweigand@de.ibm.com> writes:
> > Now this problem did come up in the s390 context, but it is still
> > not specific to s390. In fact, I'm just now involved in discussions
> > on the Cell BE side where the requirement to implement the very
> > same optimization (internal use of 64-bit registers in 32-bit ABI
> > code running under a 64-bit kernel) on *PowerPC* came up.
>
> Using the full 64-bit integer register on a 64-bit PowerPC kernel is
> not safe wrt signals/context switches. Unless it has changed recently,
> the 64-bit PowerPC Linux kernel only save/restores 32 bits of the
> integer registers for 32-bit mode programs. Even if the kernel were
> to save/restore the whole 64-bits, you'd still have problems due to
> the ucontext/sigcontext for 32-bit apps only containing space for
> 32-bit registers.
I'm aware of those issues (b.t.w. we have the same problems on s390).
That's why the PowerPC kernel folks are involved in the discussion;
my understanding is that there is rough consensus on how this can be
solved on the kernel side (*without* breaking user space ABI).
The context switch already saves full 64-bit register contents, but
signal handler invocation is a problem. The suggested solution is
to use the existing sigcontext structure to save the low 32-bit
halves of registers, and use an extended area further up on the
user stack to save the high 32-bit halves. This allows programs
using the old sigcontext to continue to work, while at the same
time allowing new programs to access/modify the high 32-bit in
the extended structure as well.
I understand ucontext and jmp_buf should *not* be extended to avoid
ABI breakage; they will still always have the low 32-bit halves only.
However, as the high 32-bit halves are considered call-clobbered,
that should still allow setjmp/longjmp and getcontext/setcontext to
work as expected.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com