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: David Daney <david dot s dot daney at gmail dot com>, "Kevin D. Kissell" <kevink at paralogos dot com>, David Daney <ddaney dot cavm at gmail dot com>, <libc-alpha at sourceware dot org>, Leonid <Leonid dot Yegoshin at imgtec dot com>
- Cc: <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: Tue, 7 Oct 2014 13:22:18 +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> <54333B9C dot 2040302 at paralogos dot com> <54336CED dot 3040106 at gmail dot com> <5433D429 dot 3020804 at imgtec dot com>
On 07/10/14 12:53, James Hogan wrote:
> On 07/10/14 05:32, David Daney wrote:
>> If the kernel automatically allocated the emulation locations, what
>> would happen if there were a signal that interrupted the emulation, and
>> the signal handler did a longjump to somewhere else? How would we clean
>> up the now unused emulation memory allocations?
>
> AFAICT, Leonid's implementation also has this problem, and that has a
> separate stack of emuframes per thread managed completely by the kernel.
>
> Essentially the kernel doesn't manage the stack, userland does, and
> userland can choose to skip over sigframes and emuframes with siglongjmp
> without telling the kernel.
>
> Userland can even switch between contexts (which includes stack) with
> setcontext (coroutines etc) which breaks the assumption in Leonid's
> patches that emuframes will be completed in reverse order to them being
> started, again demonstrating that it is essentially userland that
> manages the stack.
>
> I think any attempt by the kernel to keep track of user stacks (e.g. by
> storing a stack pointer along with the emuframe so that unused emuframes
> can be discarded later when stack pointer goes high again) will be
> foiled by setcontext.
>
> Hmm, I can't see a way forward that doesn't involve invasive userland
> handling & ABI changes other than giving up with non-executable stacks
> or limiting permitted instructions in delay slots to those Linux knows
> how to emulate directly.
Would it work for a signal encountered during branch delay slot
emulation (maybe where the PC is pointing at that magic location the
kernel uses for emulation) to be treated as a return from emulation, but
leaving the user PC pointing to the original branch (with Cause.BD=1 I
suppose) prior to handling the signal, so that no more than one emuframe
is needed by each thread at a time?
Cheers
James