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 <david dot s dot daney at gmail dot com>
- To: 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, 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, 06 Oct 2014 21:50:47 -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> <543334CE dot 8060305 at caviumnetworks dot com> <20141007004915 dot GF23797 at brightrain dot aerifal dot cx>
On 10/06/2014 05:49 PM, Rich Felker wrote:
On Mon, Oct 06, 2014 at 05:33:18PM -0700, David Daney wrote:
[...]
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
My experience has been that hardware and software developers focused
on a particular hardware target are generally unqualified to make
decisions that affect the design and operation of libc or the kernel.
They are not experts in these areas. It was apparent early on in this
thread, when you mentioned the idea that "not all threads would need
fpu support", that you were thinking from a standpoint of custom
low-level software and not a general purpose libc that cannot read the
application author's mind.
Not at all, I was thinking of soft-float ABIs, as they never execute FP
instructions, and are often used on systems with no FPU. In fact many
non-FPU systems never execute any hard-float code. So those system
should not suffer large performance regressions from any change made to
support a non-executable stack.
We use GLibC on many soft-float only systems, and I would posit that
GLibC is a general purpose libc.
It seems nobody had thought of the
impossibility of doing lazy setup (inability to handle failure) and
the necessity of always initializing this stuff at pthread_create
time, either. Design issues like this should be run by experts in the
libc area early on, not as an afterthought.
I bow down to the experts, as obviously I know nothing about:
1) The Linux kernel
2) The MIPS architecture.
3) Library design.
4) C libraries and their interaction with the kernel, linker and compiler.
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.
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.
Having the kernel magically do it would be better, but I'm doubtful
that solution works anyway due to the above signal handler/nesting
issue.
So the perfect is the enemy of the good? No non-executable stack for
you, MIPS.
Rich