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]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]