Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: David Daney <ddaney@caviumnetworks.com>
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips@linux-mips.org, libc-ports@sourceware.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Richard Sandiford <rdsandiford@googlemail.com>
Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
Date: Thu, 05 Mar 2009 08:58:18 -0800	[thread overview]
Message-ID: <49B004AA.8050006@caviumnetworks.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0903051530080.6558@tp.orcam.me.uk>

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

  reply	other threads:[~2009-03-05 16:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-01  0:12 [PATCH, RFC] MIPS: Implement the getcontext API Maciej W. Rozycki
2009-03-03 16:56 ` David Daney
2009-03-04  8:19   ` Brian Foster
2009-03-04 12:17     ` Daniel Jacobowitz
2009-03-04 16:36       ` David Daney
2009-04-02 13:29         ` Ralf Baechle
2009-04-02 20:06           ` Daniel Jacobowitz
2009-03-04 15:44     ` Ralf Baechle
2009-03-04 22:25       ` David VomLehn (dvomlehn)
2009-03-04 22:25         ` David VomLehn (dvomlehn)
2009-03-04 22:34         ` David Daney
2009-03-05  7:58           ` MIPS RI/XI & trampolines [was:- [PATCH, RFC] MIPS: Implement the getcontext API ] Brian Foster
2009-03-05 17:01             ` David Daney
2009-04-02 13:38         ` [PATCH, RFC] MIPS: Implement the getcontext API Ralf Baechle
2009-04-16  3:46           ` Markus Gothe
2009-04-17  5:53             ` Ralf Baechle
2009-03-05 15:34   ` Maciej W. Rozycki
2009-03-05 16:58     ` David Daney [this message]
2009-03-05 18:23       ` David VomLehn (dvomlehn)
2009-03-05 18:23         ` David VomLehn (dvomlehn)
2009-03-05 21:36         ` Ralf Baechle
2009-03-05 21:39           ` Roland McGrath
2009-03-05 21:53           ` Joseph S. Myers
2009-03-05 22:08             ` David VomLehn (dvomlehn)
2009-03-05 22:08               ` David VomLehn (dvomlehn)
2009-04-02 13:19 ` Ralf Baechle
2009-04-15 20:19 ` Joseph S. Myers
2009-04-15 21:37   ` David Daney
2009-04-18 12:38   ` Ralf Baechle
2009-04-18 17:32     ` Joseph S. Myers
2009-04-20 19:57       ` Maciej W. Rozycki
2009-04-28 19:17       ` Aurelien Jarno
2009-04-28 19:21         ` Philippe Vachon
2009-04-28 20:19         ` Maciej W. Rozycki
2009-04-28 20:53           ` Aurelien Jarno
2009-04-28 21:47             ` Maciej W. Rozycki
  -- strict thread matches above, loose matches on Subject: below --
2009-04-05 18:57 Graziano Sorbaioli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49B004AA.8050006@caviumnetworks.com \
    --to=ddaney@caviumnetworks.com \
    --cc=libc-ports@sourceware.org \
    --cc=linux-mips@linux-mips.org \
    --cc=macro@codesourcery.com \
    --cc=macro@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rdsandiford@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox