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: Andy Lutomirski <luto at amacapital dot net>
- To: Leonid Yegoshin <Leonid dot Yegoshin at imgtec dot com>
- Cc: 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>, 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>
- Date: Tue, 7 Oct 2014 11:44:35 -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> <54337127 dot 40806 at gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320F1E173 at LEMAIL01 dot le dot imgtec dot org> <543431DA dot 4090809 at imgtec dot com>
On Tue, Oct 7, 2014 at 11:32 AM, Leonid Yegoshin
<Leonid.Yegoshin@imgtec.com> wrote:
> Well, I am not a subscriber to mail-list, so I read it the first time and
> some notes:
>
>
> 3) The signal happened during execution of emulated instruction - signals
> are under control of kernel and we can easily delay a signal during
> execution of emulated instruction until return from do_dsemulret. It is not
> a big deal - nor code, nor performance. Thank you for good point.
If you go down this particular rabbit hole, you will never come back out.
What happens if one of those out-of-line instructions causes a
synchronous trap? What if SIGSTOP arrives before ret? What if
another thread removes the magic ret sequence?
>
> 4) The voice for doing any instruction emulation in kernel - it is not a
> MIPS business model to force customer to put details of all Coprocessor 2
> instructions public. We provide an interface and the rest is a customer
> business. Besides that it is really painful to make a differentiation
> between Cavium Octeon and some another CPU instructions with the same
> opcode. On other side, leaving emulation of their instructions to them is
> not a wise after having some good way doing that multiple years.
IMO this is all backwards. If MIPS customers put proprietary
instructions into their ISA, they leave out the FPU, and they put a
proprietary insn in a branch delay slot, then I think that they
deserve a fatal signal.
There's a really easy solution for new systems: fix the toolchain.
Teach the assembler to disallow any proprietary instructions in an FP
branch delay slot.
--Andy