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
next prev parent 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