linux-mips
[Top] [All Lists]

Re: [PATCH, RFC] MIPS: Implement the getcontext API

To: David Daney <ddaney@caviumnetworks.com>
Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
From: "Maciej W. Rozycki" <macro@codesourcery.com>
Date: Thu, 5 Mar 2009 15:34:45 +0000 (GMT)
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org, libc-ports@sourceware.org, "Maciej W. Rozycki" <macro@linux-mips.org>
In-reply-to: <49AD6139.60209@caviumnetworks.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <alpine.DEB.1.10.0902282326580.4064@tp.orcam.me.uk> <49AD6139.60209@caviumnetworks.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Alpine 1.10 (DEB 962 2008-03-14)
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

<Prev in Thread] Current Thread [Next in Thread>