Skip to content

V
V8
Switch branch/tag
  1. 01 Mar, 2021 1 commit
  3. 22 Feb, 2021 1 commit
  5. 15 Feb, 2021 1 commit
  7. 12 Feb, 2021 3 commits
    • Leszek Swirski's avatar
      [sparkplug] Change Sparkplug to Baseline · c913ef3a
      Leszek Swirski authored 
      Currently we sometimes refer to baseline code or the baseline compiler
by its codename (Sparkplug). The codename is fun, but we should be
consistent and call things by one name or the other. Following the
pattern of Ignition stuff being called "interpreter", we call Sparkplug
"baseline", and leave the codename only in flags and variants.

Bug: v8:11420
Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72696}
      c913ef3a
    • Benedikt Meurer's avatar
      [stack-traces] Simplify and speedup stack trace collection. · eed0d27c
      Benedikt Meurer authored 
      Following up on https://crrev.com/c/2689185, this CL significantly
simplifies the whole implementation of the stack trace capturing.

Before this CL, capturing any stack trace (for the purpose of the API or
Error.stack) would roughly work like this:

  1. The CaptureStackTrace() function uses the StackFrameIterator to
     walk the system stack. For each native frame it uses the
     FrameSummary abstraction to get all (including potentially inlined)
     frames. For each of those it appends a record consisting of six
     elements to a FrameArray (this holds pointers to the actual
     closures and receivers).
  2. Afterwards the FrameArray is shrinked to the required size, and a
     new FixedArray is allocated, and initialized with new
     StackTraceFrame objects where each holds a reference to the
     FrameArray, the index of the frame, and an initially uninitialized
     StackFrameInfo reference. This new FixedArray is then returned from
     CaptureStackTrace() and either stored on a message object or
     provided to the API as v8::StackTrace.

The new approach removes a lot of the machinery in between and directly
creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
These StackFrameInfo objects are directly exposed as v8::StackFrame on
the public API, and they hold the six fields that were previously stored
flat in the FrameArray. This not only avoids a lot of copying around of
data and creation of temporary objects and handles, but most importantly
unifies and simplifies the stack frame function inside StackFrameInfo,
so you no longer need to wonder which function / object might be
responsible for a certain API.

There's still a lot of room for improvement. In particular we currently
don't cache the source position for a given StackFrameInfo (or
globally), but rather recompute it every time. This is still very fast,
significantly faster than the previous approach.

There are some notable (potentially user visible) changes:

  - The CallSite#GetPosition() method now consistently returns the
    Wasm module relative bytecode offset for all Wasm frames (previously
    it'd return the function relative bytecode offset for non-asm.js
    Wasm frames).
  - The column and line numbers returned from StackFrameInfo methods are
    consistently 1-based now, instead of sometimes being 0-based (Wasm)
    and sometimes being 1-based (JS and asm.js Wasm). The only
    potentially noticable difference is that for
    CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
    that was wrong and useless anyways.
  - CallSite#GetThis() would sometimes return the_hole, another bug
    flushed out by this CL.

The CL also contains some other not noteworthy drive-by-cleanups.

Fixed: chromium:1057211
Bug: chromium:1077657, chromium:1069425, v8:8742
Bug: chromium:1127391, chromium:1098530, chromium:981541
Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72694}
      eed0d27c
    • Leszek Swirski's avatar
      [sparkplug] Upstream Sparkplug · c053419e
      Leszek Swirski authored 
      Sparkplug is a new baseline, non-optimising second-tier compiler,
designed to fit in the compiler trade-off space between Ignition and
TurboProp/TurboFan.

Design doc:
https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing

Bug: v8:11420
Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72686}
      c053419e
  9. 28 Jan, 2021 1 commit
    • Clemens Backes's avatar
      [frame] Remove redundant unchecked_code implementations · d1e6dcd9
      Clemens Backes authored 
      1) Wasm code is not associated with a Code object, hence
   WasmFrame::unchecked_code will always return a null object. Hence we
   can use the default implementation from TypedFrame and avoid the
   lookup on the heap which will always fail.
2) InternalFrame inherits from TypedFrame, hence can also reuse the
   unchecked_code implementation from TypedFrame.
3) Use "{}" instead of "Code()" to return "nothing".

R=jkummerow@chromium.org

Bug: v8:11074
Change-Id: I142d2f21c05bf87cafa5ba6e7f463510be6c70bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653229Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72410}
      d1e6dcd9
  11. 20 Jan, 2021 1 commit
  13. 18 Jan, 2021 1 commit
  15. 01 Dec, 2020 1 commit
  17. 10 Nov, 2020 1 commit
  19. 19 Oct, 2020 4 commits
  21. 16 Oct, 2020 1 commit
  23. 15 Oct, 2020 1 commit
  25. 14 Oct, 2020 1 commit
  27. 28 Sep, 2020 1 commit
    • Alex Kodat's avatar
      [debug] Restore StepNext on correct frame for RestoreDebug · 9329f558
      Alex Kodat authored 
      When an Isolate in a multi-threaded environment is being debugged
and a thread does a Step Over (StepNext internally) one-shot
breaks are created in the code at the stack frame where the
StepNext occurred. However, if the stepped-over statement had
a function call and the called function (or some function that
it called) unlocked the Isolate (via a C++ function call) and
another thread then locked the Isolate, an ArchiveDebug would
be done which would save the fact that a StepNext is active and
the call frame depth of the StepNext. The one-shot breaks would
then be cleared to avoid stopping the now running thread.

When the original thread that did the StepNext relocks the Isolate,
a RestoreDebug is done which, seeing that a StepNext was active
calls PrepareDebug which assumes that the StepNext must be for
the current JS frame which is usually correct, but not in this
case. This results in the StepNext break actually occurring in the
function that called the C++ function not in the function where
the StepNext was originally done. In addition, the function where
the break now happens must necessarily be deoptimized if
optimized, and debug code and a source map table created if one
doesn't already exists though this is largely invisible to the
user.

Occasionally, a crash/core dump also occurs because the stack
guard is restored after the debugging environment is restored in
the RestoreThread code which can prevent the compiler from being
called to generate the source map table (for the incorrect
function) since the stack guard is another thread's stack guard,
and so might appear that the stack guard has been gone past so
the compiler is not called, resulting in there being no source
map table. But PrepareStep ends up calling the BreakIterator
(via the DebugInfo constructor) which assumes there is a source
map table so we get a crash.

The fix is to have PrepareStep to skip to the frame where the
StepNext was done before doing its thing. Since the only
PrepareStepcaller that requires a frame other than the current
frame, is RestoreDebug, a target frame parameter was added to
PrepareStep that's set by RestoreDebug and defaults to -1
indicating to use the current frame for all other callers.

While this made the order of the debug environment and stack
guard no longer cause an obvious problem, it still felt wrong
to defer restoration of the stack guard until after something
as potentially complex as PrepareStep might be called, so the
order of RestoreDebug and RestoreStackGuard calls were reversed.

Bug: v8:10902
Change-Id: I174e254e72414c827e113aec142f1d329ebe73d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405932
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70152}
      9329f558
  29. 23 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [profiler] Include the generic js-to-wasm builtin in profiles · f20230af
      Clemens Backes authored 
      This CL fixes two things:
1) It properly creates code entries for the generic js-to-wasm builtin
(others are left out because we don't want to include all builtins in
profiles).
2) It includes js-to-wasm frames in profiles. The generic js-to-wasm
builtin will map to that frame type in the future (see referenced
bug). js-to-wasm frames are currently included because they are wrongly
mapped to OPTIMIZED frames by the SafeStackTraceIterator.

R=petermarshall@chromium.org
CC=ahaas@chromium.org, evih@google.com

Bug: v8:10701
Change-Id: I26e3fa6901890e041feab7c001069e67a616c986
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416495Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70095}
      f20230af
  31. 11 Sep, 2020 1 commit
  33. 18 Aug, 2020 1 commit
  35. 17 Aug, 2020 1 commit
  37. 17 Jun, 2020 1 commit
    • Georgia Kouveli's avatar
      [arm64][cfi] Skip authenticating return addresses in the profiler · bf383a87
      Georgia Kouveli authored 
      The SafeStackFrameIterator, used in the profiler, sometimes uses the
link register instead of a return address stored on the stack, to get
more accurate results. This happens in particular for bytecode handlers
that do not create a stack frame. Authentication of PC for those frames
would fail in the SafeStackFrameIterator, as the "PC address" would not
point to a stack location with a signed return address, but instead to
a member of the SafeStackFrameIterator class where the value of the link
register was stored. We address this by skipping authentication of PCs
in the profiler.

Bug: v8:10026
Change-Id: I331c6c68e703db766be1891efffa69c2f9794e8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2242954Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#68388}
      bf383a87
  39. 09 Jun, 2020 1 commit
  41. 13 May, 2020 1 commit
  43. 11 May, 2020 1 commit
  45. 08 May, 2020 1 commit
  47. 06 May, 2020 1 commit
  49. 24 Apr, 2020 2 commits
  51. 03 Apr, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Reorganize source position lookup · 3aedafbb
      Clemens Backes authored 
      Instead of two copies of the lookup code in frames.cc and wasm-debug.cc,
put one lookup method on the WasmCode. This is where it belongs really,
since the WasmCode is the main input to the function (besides the
offset).

Also refactor how source positions are computed in WasmCompiledFrame.
Avoid going through the summary, which is unneccessarily complex. This
also adds another {byte_offset} accessor which can be used for
debugging.

Bug: v8:10235
Change-Id: I5c545ee302754b86009f09bedc5ff6e39ba664f6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2135726Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66991}
      3aedafbb
  53. 16 Mar, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Load register values from DebugBreak frame · ae03752f
      Clemens Backes authored 
      This implements inspection of live registers on breakpoints in Liftoff.
To that end, the frame pointer of the WasmDebugBreak frame is remembered
when iterating the stack. Based on a platform-specific implementation of
{WasmDebugBreakFrameConstants}, the offset of the respective register
within that frame is computed, and the value is read from the frame.

As a drive-by, the wasm debug side table is storing register codes as
liftoff codes, which can also store register pairs (needed for i64 on
32-bit platforms, and for SIMD, which is not supported yet).

R=jkummerow@chromium.org
CC=thibaudm@chromium.org

Bug: v8:10222
Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66719}
      ae03752f
  55. 02 Mar, 2020 2 commits
  57. 13 Feb, 2020 1 commit
    • Georgia Kouveli's avatar
      Reland "[arm64] Protect return addresses stored on stack" · 73f88b5f
      Georgia Kouveli authored 
      This is a reland of 137bfe47

Original change's description:
> [arm64] Protect return addresses stored on stack
> 
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack.  The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
> 
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
> 
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
> 
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

Bug: v8:10026
Change-Id: Id1adfa2e6c713f6977d69aa467986e48fe67b3c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051958Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#66254}
      73f88b5f
  59. 12 Feb, 2020 2 commits
    • Nico Hartmann's avatar
      Revert "[arm64] Protect return addresses stored on stack" · 6a9a67d9
      Nico Hartmann authored 
      This reverts commit 137bfe47.

Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Arm%20-%20debug/13072

Original change's description:
> [arm64] Protect return addresses stored on stack
> 
> This change uses the Arm v8.3 pointer authentication instructions in
> order to protect return addresses stored on the stack.  The generated
> code signs the return address before storing on the stack and
> authenticates it after loading it. This also changes the stack frame
> iterator in order to authenticate stored return addresses and re-sign
> them when needed, as well as the deoptimizer in order to sign saved
> return addresses when creating new frames. This offers a level of
> protection against ROP attacks.
> 
> This functionality is enabled with the v8_control_flow_integrity flag
> that this CL introduces.
> 
> The code size effect of this change is small for Octane (up to 2% in
> some cases but mostly much lower) and negligible for larger benchmarks,
> however code size measurements are rather noisy. The performance impact
> on current cores (where the instructions are NOPs) is single digit,
> around 1-2% for ARES-6 and Octane, and tends to be smaller for big
> cores than for little cores.
> 
> Bug: v8:10026
> Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66239}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,neis@chromium.org,georgia.kouveli@arm.com

Change-Id: I57d5928949b0d403774550b9bf7dc0b08ce4e703
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10026
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2051952Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66242}
      6a9a67d9
    • Georgia Kouveli's avatar
      [arm64] Protect return addresses stored on stack · 137bfe47
      Georgia Kouveli authored 
      This change uses the Arm v8.3 pointer authentication instructions in
order to protect return addresses stored on the stack.  The generated
code signs the return address before storing on the stack and
authenticates it after loading it. This also changes the stack frame
iterator in order to authenticate stored return addresses and re-sign
them when needed, as well as the deoptimizer in order to sign saved
return addresses when creating new frames. This offers a level of
protection against ROP attacks.

This functionality is enabled with the v8_control_flow_integrity flag
that this CL introduces.

The code size effect of this change is small for Octane (up to 2% in
some cases but mostly much lower) and negligible for larger benchmarks,
however code size measurements are rather noisy. The performance impact
on current cores (where the instructions are NOPs) is single digit,
around 1-2% for ARES-6 and Octane, and tends to be smaller for big
cores than for little cores.

Bug: v8:10026
Change-Id: I0081f3938c56e2f24d8227e4640032749f4f8368
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1373782
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66239}
      137bfe47
  61. 27 Dec, 2019 1 commit
  63. 03 Dec, 2019 1 commit