[Webkit-unassigned] [Bug 20760] Implement support for x86 Linux in CTI

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20760





------- Comment #16 from barraclough at apple.com  2008-09-11 05:12 PDT -------
> Things that need fixed:
> 1) The inline assembly mess that I mentioned in a previous comment.

Hmmm, JIT generating these trampolines is certainly an option, though obviously
adds a small unnecessary startup cost.  Fixing this for OS X / Linux is easy,
since they use the same asm syntax,

    #if PLATFORM(DARWIN)
    #define SYMBOL_STRING(name) "_" #name
    #else
    #define SYMBOL_STRING(name) #name
    #endif

then just,

    ".globl " SYMBOL_STRING(ctiVMThrowTrampoline) "\n"

etc.  Which will be a lot less extra code than would be required to wind up a
whole extra run through the JIT to generate these... that said, unifying the
windows asm is a bit more of a problem.  May be worth waiting 'til we have
x86_64, see how integrating it's trampolines works using either of these ideas.

> 2) I'm not sure why Linux needs the same emitRestoreArgumentReference madness
> that Windows needs.  Perhaps Gavin can shed some light on this?

This requirement is tied to this change:
+#if 1 || COMPILER(MSVC)
So, in order to access the args passed into the JIT code, on OS X we take the
address of the first arg & peek back up the stack to read them.  On windows, we
basically do the same thing, but the compiler seems to screw up.  To prevent it
from seeing what is going on, we load the first arg with a pointer to...
itself, so instead of taking the address of the first arg and indexing up from
here, we can just read the value of the first arg, and index up from here.

This means that on OS X the value of the arg passed into Machine::cti_*
functions is never set – since it is never read – we only every use the address
of the arg, to find other things higher up on the stack.  On windows we have to
maintain the first arg as a pointer to itself, an update it at any point it
might have been overwritten.

The cleanest and fastest solution would be to get Linux working like OS X, if
we can get the compiler to behave itself – so first I'd suggest seeing if this
change ("1 || ") was absolutely necessary.  If this fails then one quick thing
that might be worth a try would be to apply the patch I'm about to add & see if
it helps.  We currently try to mark the args to the JIT code that are modified
from Machine::cti_ methods as volatile to try to prevent the compiler from
optimizing out the writes (on the misapprehension that the stack belongs to it
;-) ), but the volatile is in the wrong place.  Fixing this might make the
compiler on Linux play nicer. 

> 3) We have no PLATFORM macro for Linux, only the generic UNIX macro.  Do all
> x86 Unix platforms use the same ABI?  Do we need to introduce a LINUX define
> and target some of these changes specifically at Linux?

I believe all x86 Unicies follow the SysV ABI (e.g.
http://math-atlas.sourceforge.net/devel/assembly/abi386-4.pdf), and would think
we should probably be able to assume so, unless we run into an evidence to the
contrary.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.