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: David Daney <ddaney at caviumnetworks dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Andy Lutomirski <luto at amacapital dot net>, David Daney <ddaney dot cavm at gmail dot com>, <libc-alpha at sourceware dot org>, <linux-kernel at vger dot kernel dot org>, <linux-mips at linux-mips dot org>, David Daney <david dot daney at cavium dot com>
- Date: Mon, 6 Oct 2014 17:33:18 -0700
- 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>
On 10/06/2014 05:05 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 04:48:52PM -0700, David Daney wrote:
On 10/06/2014 04:38 PM, Andy Lutomirski wrote:
On 10/06/2014 02:58 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 02:45:29PM -0700, David Daney wrote:
[...]
This is a huge ill-designed mess.
Amen.
Can the kernel not just emulate the instructions directly?
In theory it could, but since there can be implementation defined
instructions, there is no way to achieve full instruction set
coverage for all possible machines.
Is the issue really implementation-defined instructions with delay
slots?
It is the instructions in the delay slots, not the branch instructions
themselves that are of interest. But, for the sake of the arguments,
this is not a critical point.
If so it sounds like a made-up issue.
It is not a made up issue.
If you want an architecture that has a well defined instruction set,
stick with x86, Intel will tell you what is good for you and you will
take whatever they give you.
If you want an architecture where you can add implementation defined
instructions to do whatever you want, then you use an architecture like
MIPS.
They're not going to
occur in real binaries. Certainly a compiler is not going to generate
implementation-defined instructions,
Why not? It will emit any instructions we care to make it emit. If we
want it to emit crypto instructions with patented algorithms, then it
will do that. But we would still like to use a generic kernel with
generic FPU support.
The most straight forward way (and the currently implemented way) of
doing this is to execute the instructions in question out-of-line (on
the userspace stack).
The question here is: What is the best way to get to a non-executable
stack.
The consensus among MIPS developers is that we should continue using the
out-of-line execution trick, but do it somewhere other than in stack memory.
One way of doing this is to have the kernel magically generate thread
local memory regions.
Another option is to have userspace manage the out-of-line execution areas.
As is often the case, each approach has different pluses and minuses.