Skip webkit/function-apply-aliased.js when running on simulators.

Skip webkit/function-apply-aliased.js when running on simulators.

The webkit/function-apply-aliased.js test fails on simulators (both MIPS
and ARM) as the printed output does not match to the expected. The
failing test forces a stack overflow exception and the ToString()
operation of the exception object fails because of an other stack
overflow and returns an empty string.

The problem is that on hardware a common JS and C stack is used so the
stack overflow can be caught in C functions also while on simulator
separated JS and C stacks are used.

This patch adds a "sim" condition to test .status files to skip tests
only on simulator.

LOG=N
BUG=v8:3124

[Paul Lind, 2014-01-29 17:53:31]

LGTM, but this needs review from v8 team ... PTAL.

Balázs you might want to edit the issue subject to "Skip
webkit/function-apply-aliased.js when running on simulators", which  is more
descriptive of this change. 

Adding the sim option to the test runner & status files is just the plumbing to
make that happen.

[Jakob Kummerow, 2014-01-30 09:51:09]

More fine-grained conditional test expectations seem to be all the rage these
days, and for the record, I don't like that trend. If at all possible, the test
runner should always run the same tests and always in the same way; anything
else is a slippery slope to chaos and madness.

Since in this case I don't see an obvious alternative other than always skipping
this test (or at least those parts of it that exceed the stack), I'm approving
this CL, but I'd like to emphasize that I'm seeing this as a temporary solution.

LGTM with the comments below.

https://codereview.chromium.org/139233005/diff/1/test/webkit/webkit.status
File test/webkit/webkit.status (right):

https://codereview.chromium.org/139233005/diff/1/test/webkit/webkit.status#ne...
test/webkit/webkit.status:45: ['sim == True', {
Please call the variable 'simulator'. Also, you can skip the '== True' part.

https://codereview.chromium.org/139233005/diff/1/tools/run-tests.py
File tools/run-tests.py (right):

https://codereview.chromium.org/139233005/diff/1/tools/run-tests.py#newcode409
tools/run-tests.py:409: variables["sim"] = True
Overwriting this after the fact is confusing. Please move computation of the
value to before the "variables" dictionary is created, then in line 400 set it
immediately to its final value (essentially, treat "variables" as a read-only
object).

[kilvadyb, 2014-01-30 10:34:49]

https://codereview.chromium.org/139233005/diff/1/test/webkit/webkit.status
File test/webkit/webkit.status (right):

https://codereview.chromium.org/139233005/diff/1/test/webkit/webkit.status#ne...
test/webkit/webkit.status:45: ['sim == True', {
On 2014/01/30 09:51:09, Jakob wrote:
> Please call the variable 'simulator'. Also, you can skip the '== True' part.

Done.

https://codereview.chromium.org/139233005/diff/1/tools/run-tests.py
File tools/run-tests.py (right):

https://codereview.chromium.org/139233005/diff/1/tools/run-tests.py#newcode409
tools/run-tests.py:409: variables["sim"] = True
On 2014/01/30 09:51:09, Jakob wrote:
> Overwriting this after the fact is confusing. Please move computation of the
> value to before the "variables" dictionary is created, then in line 400 set it
> immediately to its final value (essentially, treat "variables" as a read-only
> object).

Done.

[Paul Lind, 2014-01-30 15:58:25]

> On 2014/01/30 09:51:09, Jakob wrote:
> I'm seeing this as a temporary solution.

Hi Jakob - I'm afraid I don't see this as temporary, given large change to
simulator to fix this properly (see
http://code.google.com/p/v8/issues/detail?id=3124). The alternative is to skip
this CL, and stop running webkits tests on the simulator. You guys don't run ARM
sim on this suite, at least on your public bots. (we run both hw & sim.) Would
you prefer we don't land this?

[Jakob Kummerow, 2014-01-30 17:32:20]

On 2014/01/30 15:58:25, Paul Lind wrote:
> Hi Jakob - I'm afraid I don't see this as temporary, given large change to
> simulator to fix this properly (see
> http://code.google.com/p/v8/issues/detail?id=3124). 

Well, yeah. Ideally the simulator should be as close to real hardware as
possible, especially for simulating error conditions. Then again this does seem
to be a pretty big change, and I'm not sure it's worth it. I haven't looked
closely; maybe there's a reasonably easy way to catch stack overflows at some
choke point at the simulator <-> runtime boundary.

Another approach would be to change the test. How much value do the three calls
that cause RangeErrors provide? Maybe we can just remove them. Or we could split
the test into two tests: one that always runs everywhere (with the succeeding
calls), one that's skipped entirely for simulator-using architectures.

> The alternative is to skip
> this CL, and stop running webkits tests on the simulator. You guys don't run
ARM
> sim on this suite, at least on your public bots. 

I've noticed that too today, and it surprised me. We should probably add the
webkit tests to one of the ARM simulator bots.

> (we run both hw & sim.) Would you prefer we don't land this?

I've said LGTM to express "it's OK to land this". Thanks for asking, though.

[Paul Lind, 2014-01-30 18:06:33]

Committed as r18959.