Skip to content

V
V8
Switch branch/tag
  1. 07 Dec, 2018 4 commits
  3. 06 Dec, 2018 1 commit
  5. 05 Dec, 2018 3 commits
  7. 04 Dec, 2018 5 commits
  9. 30 Nov, 2018 2 commits
  11. 29 Nov, 2018 3 commits
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored 
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.

The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.

The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.

All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.

Patchset 1 is the original CL.

R=mstarzinger@chromium.org

Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 6c8b4102
      Peter Marshall authored 
      This is a reland of d5f4a33e
Landing with test disabled for now.

Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}

TBR=v8-mips-ports@googlegroups.com
TBR=jgruber@chromium.org

Bug: v8:8464, v8:7202
Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf
Reviewed-on: https://chromium-review.googlesource.com/c/1354466
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57935}
      6c8b4102
    • Michael Achenbach's avatar
      Revert "Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"" · 76786104
      Michael Achenbach authored 
      This reverts commit ddaa1f0a.

Reason for revert:
Still flaky on windows. Maybe reland and keep skipped on windows?
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826

Original change's description:
> Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
> 
> This is a reland of d5f4a33e
> 
> Original change's description:
> > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
> >
> > Before fast C calls, store the current FP and PC on the isolate. When
> > iterating frames in SafeStackFrameIterator, check if these fields are
> > set and start iterating at the calling frame's FP instead of the current
> > FP, which will be in C++ code. We need to do this because c_entry_fp is
> > not set on the Isolate for Fast-C-Calls because we don't build an exit
> > frame.
> >
> > This change makes stack samples that occur within 'Fast-C-Calls'
> > iterable, meaning we can properly attribute ticks within the JS caller.
> >
> > Fast-C-Calls can't call back into JS code, so we can only ever have one
> > such call on the stack at a time, allowing us to store the FP on the
> > isolate rather than the stack.
> >
> > TBR=v8-mips-ports@googlegroups.com
> >
> > Bug: v8:8464, v8:7202
> > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> > Reviewed-by: Alexei Filippov <alph@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#57896}
> 
> TBR=v8-mips-ports@googlegroups.com
> TBR=jgruber@chromium.org
> 
> Bug: v8:8464, v8:7202
> Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
> Reviewed-on: https://chromium-review.googlesource.com/c/1354042
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57912}

TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com

Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1354461Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57925}
      76786104
  13. 28 Nov, 2018 3 commits
    • Peter Marshall's avatar
      Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · ddaa1f0a
      Peter Marshall authored 
      This is a reland of d5f4a33e

Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}

TBR=v8-mips-ports@googlegroups.com
TBR=jgruber@chromium.org

Bug: v8:8464, v8:7202
Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
Reviewed-on: https://chromium-review.googlesource.com/c/1354042Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57912}
      ddaa1f0a
    • Maya Lekova's avatar
      Revert "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame" · 2f530d5c
      Maya Lekova authored 
      This reverts commit d5f4a33e.

Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967

Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
> 
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
> 
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
> 
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
> 
> TBR=v8-mips-ports@googlegroups.com
> 
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}

TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com

Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1352302Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57899}
      2f530d5c
    • Peter Marshall's avatar
      [cpu-profiler] Fix stack iterability for fast C calls with no exit frame · d5f4a33e
      Peter Marshall authored 
      Before fast C calls, store the current FP and PC on the isolate. When
iterating frames in SafeStackFrameIterator, check if these fields are
set and start iterating at the calling frame's FP instead of the current
FP, which will be in C++ code. We need to do this because c_entry_fp is
not set on the Isolate for Fast-C-Calls because we don't build an exit
frame.

This change makes stack samples that occur within 'Fast-C-Calls'
iterable, meaning we can properly attribute ticks within the JS caller.

Fast-C-Calls can't call back into JS code, so we can only ever have one
such call on the stack at a time, allowing us to store the FP on the
isolate rather than the stack.

TBR=v8-mips-ports@googlegroups.com

Bug: v8:8464, v8:7202
Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
Reviewed-on: https://chromium-review.googlesource.com/c/1340241
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMartyn Capewell <martyn.capewell@arm.com>
Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57896}
      d5f4a33e
  15. 26 Nov, 2018 2 commits
  17. 20 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      Print readable register names · de2681c1
      Clemens Hammacher authored 
      This adds a {PrintRegister} method which prints the given register in a
readable way (e.g. "eax", ... on ia32).
This is currently only used in Liftoff. The {RegisterConfiguration}
class has the same functionality, and I plan to make
{RegisterConfiguration} also use the new {RegisterName} functions in a
follow-up CL.

R=mstarzinger@chromium.org

Bug: v8:8238, v8:8423, v8:6600
Change-Id: If03901f1d8c5b043e0097e63920ab711bd7e2d17
Reviewed-on: https://chromium-review.googlesource.com/c/1340041Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57646}
      de2681c1
  19. 19 Nov, 2018 1 commit
  21. 16 Nov, 2018 2 commits
  23. 15 Nov, 2018 1 commit
  25. 14 Nov, 2018 2 commits
  27. 12 Nov, 2018 1 commit
  29. 09 Nov, 2018 1 commit
  31. 07 Nov, 2018 2 commits
  33. 05 Nov, 2018 2 commits
  35. 02 Nov, 2018 1 commit
  37. 31 Oct, 2018 3 commits