|To:||Daniel Jacobowitz <email@example.com>|
|Subject:||Re: [PATCH, RFC] MIPS: Implement the getcontext API|
|From:||David Daney <firstname.lastname@example.org>|
|Date:||Wed, 04 Mar 2009 08:36:45 -0800|
|Cc:||Brian Foster <email@example.com>, "Maciej W. Rozycki" <firstname.lastname@example.org>, Ralf Baechle <email@example.com>, firstname.lastname@example.org, email@example.com, "Maciej W. Rozycki" <firstname.lastname@example.org>|
|References:||<alpine.DEB.email@example.com> <49AD6139.firstname.lastname@example.org> <email@example.com> <20090304121732.GA28381@caradoc.them.org>|
|User-agent:||Thunderbird 188.8.131.52 (X11/20090105)|
Daniel Jacobowitz wrote:
On Wed, Mar 04, 2009 at 09:19:28AM +0100, Brian Foster wrote:moving the signal trampoline to a vdso (which is(? was?) called, maybe misleadingly, ‘vsyscall’, on other architectures) is the obvious solution to that part of the puzzle. and yes, it is possible to maintain the ABI; the signal trampoline is still also put on the stack, and modulo XI, would work if used — the trampoline-on-stack is simply not used if there is a vdso with the signal trampoline.That won't quite retain the ABI: you need to make sure everyone locates it by using the stack pointer instead of the return pc. Fortunately, GCC uses the return PC only for instruction matching today. I have a vague memory it used to use the stack pointer but this was more reliable.
That is correct. Due to various errata the trampoline cannot always be at a fixed offset to the signal context bits. So we had to use the return PC as you indicate.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH, RFC] MIPS: Implement the getcontext API, Ralf Baechle|
|Next by Date:||Re: [PATCH V2] oprofile: VR5500 performance counter driver, M. Asselstine|
|Previous by Thread:||Re: [PATCH, RFC] MIPS: Implement the getcontext API, Daniel Jacobowitz|
|Next by Thread:||Re: [PATCH, RFC] MIPS: Implement the getcontext API, Ralf Baechle|
|Indexes:||[Date] [Thread] [Top] [All Lists]|