Bug 126093 - Repatch write barrier slow path call doesn't align the stack in the presence of saved registers
Summary: Repatch write barrier slow path call doesn't align the stack in the presence ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Mark Hahnenberg
URL:
Keywords:
Depends on:
Blocks: 121074
  Show dependency treegraph
 
Reported: 2013-12-20 16:16 PST by Mark Hahnenberg
Modified: 2014-01-07 13:01 PST (History)
0 users

See Also:


Attachments
Patch (8.54 KB, patch)
2014-01-07 11:14 PST, Mark Hahnenberg
ggaren: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Hahnenberg 2013-12-20 16:16:35 PST
This is sort of related to (and is blocked by) bug 126092, but it's related more to the alignment of the stack at the time of the call on x86. x86 needs two extra slots to store arguments during the call. It also needs SP to be 16-byte aligned after the call pushes the return address onto the stack. Right now we're just subtracting 3 * sizeof(void*), which gives us space for the arguments and the correct alignment assuming SP was correctly aligned to start with. Unfortunately, when the ScratchRegisterAllocator saves reused registers it breaks the correct starting alignment guarantee.
Comment 1 Mark Hahnenberg 2014-01-07 10:00:52 PST
Correction to the above: the stack must be aligned at the time of the call (i.e. 16-byte aligned, then return address is pushed).
Comment 2 Mark Hahnenberg 2014-01-07 11:14:52 PST
Created attachment 220535 [details]
Patch
Comment 3 Geoffrey Garen 2014-01-07 11:18:23 PST
Comment on attachment 220535 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=220535&action=review

r=me

> Source/JavaScriptCore/jit/Repatch.cpp:798
> +    unsigned desiredAlignment = 16;

Please use StackAlignment.h instead.

> Source/JavaScriptCore/jit/Repatch.cpp:897
>  #if ENABLE(GGC)
> -    MacroAssembler::Call writeBarrierOperation = writeBarrier(stubJit, baseGPR, scratchGPR1, scratchGPR2, allocator);
> +    MacroAssembler::Call writeBarrierOperation = writeBarrier(stubJit, baseGPR, scratchGPR1, scratchGPR2, callFrameRegister, allocator);
>  #endif

For #ifdefs like this, I prefer to make the call site unconditional, and make the implementation of writeBarrier() conditional on #ENABLE(GGC). That removes distractions from the code.
Comment 4 Mark Hahnenberg 2014-01-07 11:20:15 PST
> For #ifdefs like this, I prefer to make the call site unconditional, and make the implementation of writeBarrier() conditional on #ENABLE(GGC). That removes distractions from the code.

My main reasoning for putting it here rather than in the body is to make so as much code compiles when GGC is disabled.
Comment 5 Mark Hahnenberg 2014-01-07 11:20:58 PST
(In reply to comment #4)
> My main reasoning for putting it here rather than in the body is to make so as much code compiles when GGC is disabled.

...as possible?
Comment 6 Mark Hahnenberg 2014-01-07 13:01:37 PST
Committed r161450: <http://trac.webkit.org/changeset/161450>