This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.
- From: James Hogan <james dot hogan at imgtec dot com>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>, David Daney <david dot s dot daney at gmail dot com>, Rich Felker <dalias at libc dot org>, David Daney <ddaney at caviumnetworks dot com>
- Cc: Andy Lutomirski <luto at amacapital dot net>, David Daney <ddaney dot cavm at gmail dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, "linux-mips at linux-mips dot org" <linux-mips at linux-mips dot org>, David Daney <david dot daney at cavium dot com>, "Leonid Yegoshin" <Leonid dot Yegoshin at imgtec dot com>
- Date: Tue, 7 Oct 2014 11:52:34 +0100
- Subject: Re: [PATCH resend] MIPS: Allow FPU emulator to use non-stack area.
- Authentication-results: sourceware.org; auth=none
- References: <1412627010-4311-1-git-send-email-ddaney dot cavm at gmail dot com> <20141006205459 dot GZ23797 at brightrain dot aerifal dot cx> <5433071B dot 4050606 at caviumnetworks dot com> <20141006213101 dot GA23797 at brightrain dot aerifal dot cx> <54330D79 dot 80102 at caviumnetworks dot com> <20141006215813 dot GB23797 at brightrain dot aerifal dot cx> <543327E7 dot 4020608 at amacapital dot net> <54332A64 dot 5020605 at caviumnetworks dot com> <20141007000514 dot GD23797 at brightrain dot aerifal dot cx> <543334CE dot 8060305 at caviumnetworks dot com> <20141007004915 dot GF23797 at brightrain dot aerifal dot cx> <54337127 dot 40806 at gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320F1E173 at LEMAIL01 dot le dot imgtec dot org>
On 07/10/14 10:13, Matthew Fortune wrote:
>>>> the out-of-line execution trick, but do it somewhere other than in
>>>> stack memory.
>>> How do you answer Andy Lutomirski's question about what happens when a
>>> signal handler interrupts execution while the program counter is
>>> pointing at this "out-of-line execution" trampoline? This seems like a
>>> show-stopper for using anything other than the stack.
>> It would be nice to support, but not doing so would not be a regression
>> from current behavior.
>
> It seems appropriate to mention another issue which should be addressed as
> part of the overall FPU emulation work...
>
> From what I can see the out-of-line execution of delay slot instructions
> will break micromips R3 addiupc, and all MIPS32r6 and MIPS64r6 PC-relative
> instructions (inc load/store) as they will have the wrong base. Is there
> anything in the current set of proposals that can address this (beyond
> adding restrictions to what is ABI allowed in FPU branch delay slots)?
>
> This is an issue whether the stack is executable or not but does directly
> relate to the topic of FPU emulation. It sounds like the kernel would not
> be able to emulate a pc-relative load/store even if it was a special case
> as it would not run in the correct MM context? [be gentle, I'm no expert
> in this area].
I think special casing and emulating them in the kernel would work in
these cases, since it'd be a known set of instructions rather than
arbitrary unknown instructions, the kernel needs to read/write safely
into the user address space all the time for system calls.
Cheers
James