Commit Graph

6 Commits

Author SHA1 Message Date
Vasili Skurydzin
ab6462e883 ppc64,aix: fixed Abort() calling sequence on Aix
fixed Abort() calling sequence on platforms with function descriptors by taking
function descriptor of the External Reference object into account when calling
C code.

Change-Id: I54c04a5f1774f2768380cc5c95b1b807204335ce
Reviewed-on: https://chromium-review.googlesource.com/c/1258186
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#56356}
2018-10-03 19:40:59 +00:00
Junliang Yan
a27871d527 PPC/s390: Reland "[turboassembler] Introduce hard-abort mode"
Port d324382e1c

and

Port bd3f0a684b

Original Commit Message:

    This is a reland of a462a7854a

    Original change's description:
    > [turboassembler] Introduce hard-abort mode
    >
    > For checks and assertions (mostly for debug code, like stack alignment
    > or zero extension), we had two modes: Emit a call to the {Abort}
    > runtime function (the default), and emit a debug break (used for
    > testing, enabled via --trap-on-abort).
    > In wasm, where we cannot just call a runtime function because code must
    > be isolate independent, we always used the trap-on-abort behaviour.
    > This causes problems for our fuzzers, which do not catch SIGTRAP, and
    > hence do not detect debug code failures.
    >
    > This CL introduces a third mode ("hard abort"), which calls a C
    > function via {ExternalReference}. The C function still outputs the
    > abort reason, but does not print the stack trace. It then aborts via
    > "OS::Abort", just like the runtime function.
    > This will allow fuzzers to detect the crash and even find a nice error
    > message.
    >
    > Even though this looks like a lot of code churn, it is actually not.
    > Most added lines are new tests, and other changes are minimal.
    >
    > R=mstarzinger@chromium.org
    >
    > Bug: chromium:863799
    > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
    > Reviewed-on: https://chromium-review.googlesource.com/1142163
    > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
    > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
    > Cr-Commit-Position: refs/heads/master@{#54592}

R=clemensh@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I60023470fa07576fd313f628ade06e279d5f4927
Reviewed-on: https://chromium-review.googlesource.com/1165822
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54980}
2018-08-08 14:41:22 +00:00
Clemens Hammacher
91ab657e36 Enable TurboAssembler tests on native android
We currently don't execute the tests on android, because the error
message is redirected to the android log. What we can still to though
is ensuring that the call aborts the process, but just ignore the error
message.

R=mstarzinger@chromium.org

Bug: chromium:863799
Change-Id: I54b503849358133ffe647be83eae7a964c2ac49e
Reviewed-on: https://chromium-review.googlesource.com/1148444
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54839}
2018-08-01 12:20:17 +00:00
Clemens Hammacher
d324382e1c Reland "[turboassembler] Introduce hard-abort mode"
This is a reland of a462a7854a

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

Bug: chromium:863799
Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326
Reviewed-on: https://chromium-review.googlesource.com/1146100
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54656}
2018-07-24 15:58:46 +00:00
Sigurd Schneider
039c18e19a Speculatively revert "[turboassembler] Introduce hard-abort mode"
This reverts commit a462a7854a.

Reason for revert: Breaks a TurboAssembler test:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/7726

Original change's description:
> [turboassembler] Introduce hard-abort mode
> 
> For checks and assertions (mostly for debug code, like stack alignment
> or zero extension), we had two modes: Emit a call to the {Abort}
> runtime function (the default), and emit a debug break (used for
> testing, enabled via --trap-on-abort).
> In wasm, where we cannot just call a runtime function because code must
> be isolate independent, we always used the trap-on-abort behaviour.
> This causes problems for our fuzzers, which do not catch SIGTRAP, and
> hence do not detect debug code failures.
> 
> This CL introduces a third mode ("hard abort"), which calls a C
> function via {ExternalReference}. The C function still outputs the
> abort reason, but does not print the stack trace. It then aborts via
> "OS::Abort", just like the runtime function.
> This will allow fuzzers to detect the crash and even find a nice error
> message.
> 
> Even though this looks like a lot of code churn, it is actually not.
> Most added lines are new tests, and other changes are minimal.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: chromium:863799
> Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
> Reviewed-on: https://chromium-review.googlesource.com/1142163
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54592}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I60c011cfe262ccebbb9abf32699a9fe17e72a3c8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:863799
Reviewed-on: https://chromium-review.googlesource.com/1145431
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54597}
2018-07-20 17:28:49 +00:00
Clemens Hammacher
a462a7854a [turboassembler] Introduce hard-abort mode
For checks and assertions (mostly for debug code, like stack alignment
or zero extension), we had two modes: Emit a call to the {Abort}
runtime function (the default), and emit a debug break (used for
testing, enabled via --trap-on-abort).
In wasm, where we cannot just call a runtime function because code must
be isolate independent, we always used the trap-on-abort behaviour.
This causes problems for our fuzzers, which do not catch SIGTRAP, and
hence do not detect debug code failures.

This CL introduces a third mode ("hard abort"), which calls a C
function via {ExternalReference}. The C function still outputs the
abort reason, but does not print the stack trace. It then aborts via
"OS::Abort", just like the runtime function.
This will allow fuzzers to detect the crash and even find a nice error
message.

Even though this looks like a lot of code churn, it is actually not.
Most added lines are new tests, and other changes are minimal.

R=mstarzinger@chromium.org

Bug: chromium:863799
Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b
Reviewed-on: https://chromium-review.googlesource.com/1142163
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54592}
2018-07-20 14:44:29 +00:00