Adding Richard S. as he may be interested...
Maciej W. Rozycki wrote:
On Tue, 3 Mar 2009, David Daney wrote:
Note the libgcc currently makes the assumption that the layout of the stack
for signal handlers is fixed. The DWARF2 unwinder needs this information to
be able to unwind through signal frames (see gcc/config/mips/linux-unwind.h),
so it is already a de facto part of the ABI.
I do hope it was agreed upon at some point.
As with many things, there was no formal agreement.
I certainly cannot recall a
discussion at the linux-mips list, but I did not always follow it closely
enough either, so I may have missed the discussion.
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=473957B6.3030202%40avtrex.com
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=4739CCD6.2080306%40avtrex.com
The interface is
meant to be internal to Linux, so the usual rule of volatility apply. The
structure is not defined in a header even.
Certainly it started out that way, but if the kernel doesn't supply
DWARF2 unwind tables for its signal trampolines (which it currently does
not), then I think using the structures is the only way for user-space
applications to unwind through signal trampolines.
I was pointing this out not as any type of objection to your plan, but
as further support for formalizing the interfaces.
Furthermore I am requesting that the kernel recognises the special meaning
of the value of one stored in the slot designated for the $zero register and
never places such a value itself there.
Seems reasonable to me as currently a zero is unconditionally stored there.
It is, but is should be architected, not assumed. Also contexts built
with the *context() functions are meant to be usable by them only --
software will still be able to assume the value in the slot when
constructed by the kernel.
Agreed.
Thanks for working on this,
David Daney
