This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH, RFC] MIPS: Implement the getcontext API
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: David Daney <ddaney at caviumnetworks dot com>
- Cc: Ralf Baechle <ralf at linux-mips dot org>, linux-mips at linux-mips dot org, libc-ports at sourceware dot org, "Maciej W. Rozycki" <macro at linux-mips dot org>
- Date: Thu, 5 Mar 2009 15:34:45 +0000 (GMT)
- Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
- References: <alpine.DEB.1.10.0902282326580.4064@tp.orcam.me.uk> <49AD6139.60209@caviumnetworks.com>
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. 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.
> > 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.
Maciej