Skip to content

V
V8
Switch branch/tag
  1. 15 Jun, 2018 1 commit
  3. 13 Jun, 2018 2 commits
  5. 06 Jun, 2018 2 commits
  7. 05 Jun, 2018 1 commit
  9. 04 Jun, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [wasm] Make stack check independent of the Isolate. · 94aac004
      Junliang Yan authored 
      Port c96ac82c

Original Commit Message:

    This makes stack checks in WasmCode independent of the underlying
    Isolate by loading the limit address from the WasmInstanceObject instead
    of embedding it into the instruction stream. It hence removes the last
    use of the Isolate field from WasmGraphBuilder.

    Additionally this introduces the notion of a "runtime stub" which
    represents stub code global to the NativeModule that can be directly
    called from each WasmCode in the same module. These stubs can act as
    trampolines via which Isolate-independent WasmCode can enter other V8
    builtins or runtime functions that remain Isolate-dependent. They will
    eventually replace the current "trampoline" in a NativeModule.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:7424
LOG=N

Change-Id: I5745a20133c930aecb80119e71ac1d8717e267bf
Reviewed-on: https://chromium-review.googlesource.com/1085276Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#53503}
      94aac004
  11. 14 May, 2018 2 commits
  13. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored 
      The idea is to mark all the branches and loads participating in array
bounds checks, and let them contribute-to/use the poisoning register.
In the code, the marks for array indexing operations now contain
"Critical" in their name. By default (--untrusted-code-mitigations),
we only instrument the "critical" operations with poisoning.

With that in place, we also remove the array masking approach based
on arithmetic.

Since we do not propagate the poison through function calls,
we introduce a node for poisoning an index that is passed through
function call - the typical example is the bounds-checked index
that is passed to the CharCodeAt builtin.

Most of the code in this CL is threads through the three levels of
protection (safe, critical, unsafe) for loads, branches and flags.

Bug: chromium:798964

Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
Reviewed-on: https://chromium-review.googlesource.com/995413
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  15. 26 Apr, 2018 3 commits
  17. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored 
      I missed one required change which was hidden behind an #if. The fix is in
the diff between Patch 1 and Patch 3.

Original message:
In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

R=mstarzinger@chromium.org

Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  19. 24 Apr, 2018 2 commits
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored 
      This reverts commit 44ea425a.

Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575

Original change's description:
> [refactoring] Remove the isolate from signatures of ExternalReferences
> 
> In this CL I remove the isolate from signatures of ExternalReference
> accessor functions where the isolate is not used. The uses of the
> isolate were already removed in previous CLs.
> 
> Changes:
> * I split the ExternalReference list in external-reference.h into
> those which need the isolate for initialization and those which do not.
> 
> * I removed the public constructors and replaced them by
>   ExternalReference::Create(). The reason is to separate external
>   creation more clearly from internal creation, because externally
>   created ExternalReferences sometimes need redirection, whereas
>   internally created ExternalReferences are just stored as they are.
>   In addition, by removing the isolate from the signature of the
>   public constructors, they suddenly exactly matched the interal
>   constructor.
> 
> * Replace all uses of the public constructors with
>   ExternalReference::Create().
> 
> * Remove the isolate from all call sites where necessary.
> 
> 
> This is a step towards making WebAssembly compilation independent of
> the isolate.
> 
> Bug: v8:7570
> R=​mstarzinger@chromium.org
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
> Reviewed-on: https://chromium-review.googlesource.com/1018982
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52768}

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

Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad
    • Andreas Haas's avatar
      [refactoring] Remove the isolate from signatures of ExternalReferences · 44ea425a
      Andreas Haas authored 
      In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

Bug: v8:7570
R=mstarzinger@chromium.org

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
Reviewed-on: https://chromium-review.googlesource.com/1018982
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52768}
      44ea425a
  21. 16 Apr, 2018 1 commit
  23. 14 Apr, 2018 2 commits
    • Junliang Yan's avatar
      PPC/s390: [stubs] Convert DoubleToIStub and MathPowStub to builtins · 5e8bc1c3
      Junliang Yan authored 
      Port a3b60675

Original Commit Message:

    This is mostly a simple copy & paste of the stub implementation from
    code-stubs-arch.cc to builtins-arch.cc.

    The conversion allows removal of a special case for the DoubleToIStub
    within the compiler & wasm pipelines, and also makes the following
    builtins isolate-independent (in conjunction with
    https://crrev.com/c/1006581):

    TFC BitwiseAnd
    TFC BitwiseOr
    TFC BitwiseXor
    TFC Exponentiate
    TFC ShiftLeft
    TFC ShiftRight
    TFC ShiftRightLogical
    TFJ AtomicsAdd
    TFJ AtomicsAnd
    TFJ AtomicsCompareExchange
    TFJ AtomicsExchange
    TFJ AtomicsLoad
    TFJ AtomicsOr
    TFJ AtomicsStore
    TFJ AtomicsSub
    TFJ AtomicsXor
    TFJ MathClz32
    TFJ MathImul
    TFJ MathPow
    TFJ NumberParseInt
    TFJ StringFromCharCode
    TFJ TypedArrayFrom
    TFJ TypedArrayOf
    TFJ TypedArrayPrototypeMap

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

Change-Id: Iee9fc5671646772625556717db052b78089c5c66
Reviewed-on: https://chromium-review.googlesource.com/1013247Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#52606}
      5e8bc1c3
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  25. 11 Apr, 2018 1 commit
  27. 10 Apr, 2018 1 commit
  29. 09 Apr, 2018 1 commit
  31. 05 Apr, 2018 1 commit
  33. 04 Apr, 2018 1 commit
  35. 29 Mar, 2018 1 commit
  37. 28 Mar, 2018 1 commit
    • Junliang Yan's avatar
      PPC: [turbofan] unify interpreter and JIT speculation poisoning · 4d6c5d4c
      Junliang Yan authored 
      Port 1ef6c437

Original Commit Message:

    This CL changes the poisoning in the interpreter to use the
    infrastructure used in the JIT.

    This does not change the original flag semantics:

    --branch-load-poisoning enables JIT mitigations as before.

    --untrusted-code-mitigation enables the interpreter mitigations
      (now realized using the compiler back-end), but does not enable
      the back-end based mitigations for the Javascript JIT. So in effect
      --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
      use the same mechanics (including changed register allocation) that
      --branch-load-poisoning enables for the JIT.

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

Change-Id: I46ee60541c48ad1e9c5ca1c2aac0d89d81c65333
Reviewed-on: https://chromium-review.googlesource.com/981935Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#52258}
      4d6c5d4c
  39. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored 
      This CL changes the poisoning in the interpreter to use the
infrastructure used in the JIT.

This does not change the original flag semantics:

--branch-load-poisoning enables JIT mitigations as before.

--untrusted-code-mitigation enables the interpreter mitigations
  (now realized using the compiler back-end), but does not enable
  the back-end based mitigations for the Javascript JIT. So in effect
  --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
  use the same mechanics (including changed register allocation) that
  --branch-load-poisoning enables for the JIT.

Bug: chromium:798964
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  41. 20 Mar, 2018 1 commit
  43. 15 Mar, 2018 1 commit
  45. 14 Mar, 2018 1 commit
  47. 05 Mar, 2018 1 commit
  49. 02 Mar, 2018 3 commits
  51. 01 Mar, 2018 1 commit
  53. 28 Feb, 2018 3 commits
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Support poisoning arguments in JavaScript. · 03caf2c2
      Junliang Yan authored 
      Port be4cd67c

Original Commit Message:

    This adds support for poisoning the stack pointer and implicit register
    arguments like the context register and the function register in the
    prologue of generated code with JavaScript linkage. The speculation
    poison is computed similarly to the interpreter by matching expected
    with actual code start addresses.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:798964
LOG=N

Change-Id: I0d015fd8a8f05982d947a4a1c0be1a825ac19d64
Reviewed-on: https://chromium-review.googlesource.com/940460Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51621}
      03caf2c2
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Better checking of code start register. · 1ce7a7f9
      Junliang Yan authored 
      Port 5586ecfc

Original Commit Message:

    This decouples the checking of the {kJavaScriptCallCodeStartRegister}
    from the deoptimization checks. We now rely more heavily on the above
    register and should check its validity more broadly. Note that there
    also is a bug fix for the ARM port contained in this change.

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

Change-Id: Ic8b58994b083c6c0ec73173120cedf6391b1c964
Reviewed-on: https://chromium-review.googlesource.com/938522Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51620}
      1ce7a7f9
    • Junliang Yan's avatar
      Reland "PPC/s390: [turbofan] Ensure instruction start is in fixed register." · 278b00c5
      Junliang Yan authored 
      This is a reland of 89737c5d.

Original change's description:
> PPC/s390: [turbofan] Ensure instruction start is in fixed register.
> 
> Port c462ddc8
> 
> Original Commit Message:
> 
>     This makes sure that {JSFunction} invocations always load the code start
>     address into the fixed {kJavaScriptCallCodeStartRegister} register. This
>     allows us to perform PC-relative operations more effective. For now this
>     only applies to code with {kCallJSFunction} linkage.
> 
> R=mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
> 
> Change-Id: If346a3cbaea820b1fcec38c5105605496961a888
> Reviewed-on: https://chromium-review.googlesource.com/938721
> Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#51608}

Change-Id: I5b118c3903847cc13e2ce228e9713f8ae55ce193
Reviewed-on: https://chromium-review.googlesource.com/940342Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51619}
      278b00c5
  55. 27 Feb, 2018 2 commits
    • Junliang Yan's avatar
      Revert "PPC/s390: [turbofan] Ensure instruction start is in fixed register." · dc65eb54
      Junliang Yan authored 
      This reverts commit 89737c5d.

Reason for revert: Sorry, missed the portion in code-generator

Original change's description:
> PPC/s390: [turbofan] Ensure instruction start is in fixed register.
> 
> Port c462ddc8
> 
> Original Commit Message:
> 
>     This makes sure that {JSFunction} invocations always load the code start
>     address into the fixed {kJavaScriptCallCodeStartRegister} register. This
>     allows us to perform PC-relative operations more effective. For now this
>     only applies to code with {kCallJSFunction} linkage.
> 
> R=​mstarzinger@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
> BUG=
> LOG=N
> 
> Change-Id: If346a3cbaea820b1fcec38c5105605496961a888
> Reviewed-on: https://chromium-review.googlesource.com/938721
> Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
> Cr-Commit-Position: refs/heads/master@{#51608}

TBR=mstarzinger@chromium.org,michael_dawson@ca.ibm.com,jyan@ca.ibm.com,joransiu@ca.ibm.com

Change-Id: I9a0810aa35ff39651397055ab53d250c2f6f09e0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/940341Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51617}
      dc65eb54
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Ensure instruction start is in fixed register. · 89737c5d
      Junliang Yan authored 
      Port c462ddc8

Original Commit Message:

    This makes sure that {JSFunction} invocations always load the code start
    address into the fixed {kJavaScriptCallCodeStartRegister} register. This
    allows us to perform PC-relative operations more effective. For now this
    only applies to code with {kCallJSFunction} linkage.

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

Change-Id: If346a3cbaea820b1fcec38c5105605496961a888
Reviewed-on: https://chromium-review.googlesource.com/938721Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51608}
      89737c5d