linux-mips
[Top] [All Lists]

Re: Adding(?) XI support to MIPS-Linux?

To: "Kevin D. Kissell" <kevink@mips.com>, linux-mips@linux-mips.org
Subject: Re: Adding(?) XI support to MIPS-Linux?
From: Brian Foster <brian.foster@innova-card.com>
Date: Thu, 12 Jun 2008 14:03:13 +0200
Cc: David Daney <ddaney@avtrex.com>, Thiemo Seufer <ths@networkno.de>, "Kevin D. Kissell" <KevinK@paralogos.com>, Andrew Dyer <adyer@righthandtech.com>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:reply-to:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=kccwkkXCQVK4PaEtjDzgJnZdQIc7ajthrp6s/BqtHrQ=; b=tcv1p138GORs2WtR9sOdD69BxPnhm2QopMCruKbTdYVnJ0CIPe9DjmFgr+3CDgkeo9 caUs9DzmitnAbofoNjZlp7ekhsnqjTo6EZZtc6nB1tyi6ChIVzPBVzx7dLuvjcgGkzvh W61eiz3Ql802eulCeMrW125iKG3w/kIJxRXfc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:reply-to:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=Sy5PrbABGJ14f9UKmtkZhiR8CWtHhmA8eqTsgSixH/O95ncmZ3T7fqDWII3r12Jt4l ili1TmVDl+LYcnz1Nvp+zM+xjfuqRNsGNH3C7mR40jkTDDXGmRnzrztqjH/aF9fPrXA7 +JIDcV3gxBD75zmSXy10xfM09W1dlcm79RfeI=
In-reply-to: <48501E9E.1040202@mips.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <200806091658.10937.brian.foster@innova-card.com> <200806111516.57406.brian.foster@innova-card.com> <48501E9E.1040202@mips.com>
Reply-to: Brian Foster <brian.foster@innova-card.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)
On Wednesday 11 June 2008 Kevin D. Kissell wrote:
> Brian Foster wrote:
> >[ ...  the FPU emulation ] trampoline, which is pushed on
> >  the user-land stack is, unlike sigreturn, not fixed code.
> >  It varies on a per-instance per-thread basis.  Hence the
> >  simple ‘vsyscall’ mechanism ((to be?) used for sigreturn)
> >  is inappropriate.
> >
> >  The trampoline is only used to execute a non-FP instruction
> >  (<instr>) in the delay slot of an FP-instruction  [ ... ]
> >
> >  Belch! ;-\  Whilst I can think of a few things that may work
> >  (temporarily change page permissions;  or go ahead and use
> >  the ‘vsyscall’ page with some interlocking magic;  or a new
> >  new dedicated per-thread page;  or ...?) none seem appealing.
>[ ... ]
> As the jerk who originally bolted the FP emulator into the MIPS kernel
> and came up with the stack trampoline hack, I can explain why it seemed
> sane at the time.  If an FP branch is emulated and to be taken, we have to
> find a way for the instruction in the delay slot to be executed prior to the
> transfer of control to the branch target.  It has to execute with the user's
> permissions.  Putting it on the user's stack and building a trampoline was
> the fairly classical way of doing it, but note that it's architecturally
> illegal to put a branch in a branch delay slot (floating point or otherwise),
> so there's no possibility of recursion.  So one only needs 3-4 words (one
> could substitute another means of validation for the cookie) per thread.

Jerk,  ;-)

 Yes, once I worked out what it was doing it all seemed cute
 (albeit I don't quite see what the danger is with recursion?).
 My “Belch!” was referring to the problems it now causes with
 non-executable stacks.

> It just has to be part of the user's address space.  I suppose
> that instead of using a few words just above the stack, one could use
> a few words just below the current "brk()" point, or, better still (but
> far more invasive) pad the text segment, which should always be
> executable, with 4 words that the kernel can find in a hurry.

 First, you need to really careful about multithreaded code
 concurrently doing FPU stuff.  That is, it's possible there
 may be more than one “live” emulated FPU delay slot in the
 same address space.  So stuffing the code into text, or
 near the brk()-point, or similar, all has concurrency issues.

 This is what makes the current on-the-stack approach neat;
 the stack _is_ per-thread so there's no concurrency mess.

 As for putting the trampoline near the brk()-point, besides
 the concurrency problem, there's also the issue that the
 containing page would have to be made user-executable (if
 temporarily).  Unless I'm confused, that page is nominally
 data (heap-ish).  With the addition of XI support, I would
 expect data to nominally also be non-executable.

cheers!
        -blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com


<Prev in Thread] Current Thread [Next in Thread>