This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
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.
Seems reasonable to me as currently a zero is unconditionally stored there.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.
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.
Thanks for working on this, David Daney
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |