Original commit message:
Move ARM64 Assembler::nop definition from header to source file
When Assembler::nop is in the header, it is considered an inline
function. With GN arg is_component_build=true, the V8_EXPORT_PRIVATE
mark on the class causes it to be exported every time the header is
included. This, in turn, produces a reference to
Register::XRegFromCode.
Register::XRegFromCode is only ever defined as an inlined function, so
that reference is never fulfilled.
Clang can avoid this using the /Fc:dllexportInlines- flag to suppress
the export of Assembler::nop and so avoid generating the reference to
Register::XRegFromCode.
MSVC does not support this flag, so this change suppresses the export
by moving Assembler::nop's definition to the .cc file. This also allows
it to use the inline definition of Register::XRegFromCode.
Bug: v8:8870
Change-Id: I1cd33195677256c9dd06c7047fe84e1b912d3151
Reviewed-on: https://chromium-review.googlesource.com/c/1478216
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59785}
Refs: 7803fa68f4
PR-URL: https://github.com/nodejs/node/pull/25852
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Original commit message:
[coverage] Extend SourceRangeAstVisitor for throw statements
The SourceRangeAstVisitor has custom logic for blocks ending with a
statement that has a continuation range. In these cases, the trailing
continuation is removed which makes the reported coverage ranges a bit
nicer.
throw Error('foo') consists of an ExpressionStatement, with a
Throw expression stored within the statement. The source range itself
is stored with the Throw, not the statement.
We now properly extract the correct AST node for trailing throw
statements.
R=jgruber@chromium.org, neis@chromium.org, yangguo@chromium.org
Bug: v8:8691
Change-Id: Ibcbab79fbe54719a8993045040349c863b139011
Reviewed-on: https://chromium-review.googlesource.com/c/1480632
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59936}
Refs: 2d08967d4a
PR-URL: https://github.com/nodejs/node/pull/26413
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Original commit message:
[snapshot] Always align embedded blob code pointer and size
Other platforms besides ARM64 Windows may also have alignment
requirements, e.g. PPC and s390. These requirements may affect
both the code pointer field and the size field, and so they
each need alignment directives because they are stored in
different sections.
Since aligning wastes a handful of bytes at most, not making
alignment conditional on the platform type seems like a good idea.
Refs: https://github.com/nodejs/node/pull/24875
Change-Id: I1f58606af294be65e74a1f107cd05fc21e032704
Reviewed-on: https://chromium-review.googlesource.com/c/1433778
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59058}
Refs: fc0ddf5512
PR-URL: https://github.com/nodejs/node/pull/25852
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Original commit message 9365d09:
[coverage] Rework continuation counter handling
This changes a few bits about how continuation counters are handled.
It introduces a new mechanism that allows removal of a continuation
range after it has been created. If coverage is enabled, we run a first
post-processing pass on the AST immediately after parsing, which
removes problematic continuation ranges in two situations:
1. nested continuation counters - only the outermost stays alive.
2. trailing continuation counters within a block-like structure are
removed if the containing structure itself has a continuation.
R=bmeurer@chromium.org, jgruber@chromium.org, yangguo@chromium.org
Bug: v8:8381, v8:8539
Change-Id: I6bcaea5060d8c481d7bae099f6db9f993cc30ee3
Reviewed-on: https://chromium-review.googlesource.com/c/1339119
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58443}
Refs: v8/v8@9365d09
Original commit message aac2f8c:
[coverage] Filter out singleton ranges that alias full ranges
Block coverage is based on a system of ranges that can either have
both a start and end position, or only a start position (so-called
singleton ranges). When formatting coverage information, singletons
are expanded until the end of the immediate full parent range. E.g.
in:
{0, 10} // Full range.
{5, -1} // Singleton range.
the singleton range is expanded to {5, 10}.
Singletons are produced mostly for continuation counters that track
whether we execute past a specific language construct.
Unfortunately, continuation counters can turn up in spots that confuse
our post-processing. For example:
if (true) { ... block1 ... } else { ... block2 ... }
If block1 produces a continuation counter, it could end up with the
same start position as the else-branch counter. Since we merge
identical blocks, the else-branch could incorrectly end up with an
execution count of one.
We need to avoid merging such cases. A full range should always take
precedence over a singleton range; a singleton range should never
expand to completely fill a full range. An additional post-processing
pass ensures this.
Bug: v8:8237
Change-Id: Idb3ec7b2feddc0585313810b9c8be1e9f4ec64bf
Reviewed-on: https://chromium-review.googlesource.com/c/1273095
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56531}
Refs: v8/v8@aac2f8c
deps: V8: backport 47d34a3
Original commit message:
Revert "[coverage] change block range to avoid ambiguity."
This reverts commit 471fef0469d04d7c487f3a08e81f3d77566a2f50.
Reason for revert: A more general fix incoming at https://crrev.com/c/1273095.
Original change's description:
> [coverage] change block range to avoid ambiguity.
>
> By moving the block range end to left of closing bracket,
> we can avoid ambiguity where an open-ended singleton range
> could be both interpreted as inside the parent range, or
> next to it.
>
> R=<U+200B>verwaest@chromium.org
>
> Bug: v8:8237
> Change-Id: Ibc9412b31efe900b6d8bff0d8fa8c52ddfbf460a
> Reviewed-on: https://chromium-review.googlesource.com/1254127
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56347}
TBR=yangguo@chromium.org,neis@chromium.org,verwaest@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:8237
Change-Id: I39310cf3c2f06a0d98ff314740aaeefbfffc0834
Reviewed-on: https://chromium-review.googlesource.com/c/1273096
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56513}
Refs: 47d34a317e
PR-URL: https://github.com/nodejs/node/pull/25429
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
Original commit message:
[CloneObjectIC] clone MutableHeapNumbers instead of referencing them
Adds a helper macro "CloneIfMutablePrimitive", which tests if the
operand is a MutableHeapNumber, and if so, clones it, otherwise
returning the original value.
Also modifies the signature of "CopyPropertyArrayValues" to take a
"DestroySource" enum, indicating whether or not the resulting object is
supplanting the source object or not, and removes all default
parameters from that macro (which were not used anyways).
This corrects the issue reported in chromium:901301, where
StaNamedOwnProperty was replacing the value of a MutableHeapNumber
referenced by both the cloned object and the source object.
BUG=chromium:901301, v8:7611
R=cbruni@chromium.org, jkummerow@chromium.org
Change-Id: I43df1ddc84dfa4840e680b6affeba452ce0b6629
Reviewed-on: https://chromium-review.googlesource.com/c/1318096
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57304}
PR-URL: https://github.com/nodejs/node/pull/25101
Refs: bf84766a2c
Fixes: https://github.com/nodejs/node/issues/25089
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Original commit message:
[heap-profiler] Fix a use-after-free when snapshots are deleted
If a caller starts the sampling heap profiler and takes a snapshot,
and then deletes the snapshot before the sampling has completed, a
use-after-free will occur on the StringsStorage pointer.
The same issue applies for StartTrackingHeapObjects which shares the
same StringsStorage object.
Bug: v8:8373
Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643
Reviewed-on: https://chromium-review.googlesource.com/c/1301477
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57114}
PR-URL: https://github.com/nodejs/node/pull/24272
Refs:
b87d408f65
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Original commit message:
[api] Allow embedder to construct an Array from Local<Value>*
Currently to obtain a v8::Array out of a C array or a std::vector,
one needs to loop through the elements and call array->Set() multiple
times, and these calls go into v8::Object::Set() which can be slow.
This patch adds a new Array::New overload that converts a
Local<Value>* with known size into a Local<Array>.
Change-Id: I0a768f0e18eec51e78d58be455482ec6425ca188
Reviewed-on: https://chromium-review.googlesource.com/c/1317049
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57261}
Refs: 0483e9a9ab
PR-URL: https://github.com/nodejs/node/pull/24125
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Original commit message:
[heap-profiler] Fix a use-after-free when snapshots are deleted
If a caller starts the sampling heap profiler and takes a snapshot,
and then deletes the snapshot before the sampling has completed, a
use-after-free will occur on the StringsStorage pointer.
The same issue applies for StartTrackingHeapObjects which shares the
same StringsStorage object.
Bug: v8:8373
Change-Id: I5d69d60d3f9465f9dd3b3bef107c204e0fda0643
Reviewed-on: https://chromium-review.googlesource.com/c/1301477
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57114}
PR-URL: https://github.com/nodejs/node/pull/24272
Refs:
b87d408f65
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Daniel Bevenius <daniel.bevenius@gmail.com>
Original commit message:
[api] Allow embedder to construct an Array from Local<Value>*
Currently to obtain a v8::Array out of a C array or a std::vector,
one needs to loop through the elements and call array->Set() multiple
times, and these calls go into v8::Object::Set() which can be slow.
This patch adds a new Array::New overload that converts a
Local<Value>* with known size into a Local<Array>.
Change-Id: I0a768f0e18eec51e78d58be455482ec6425ca188
Reviewed-on: https://chromium-review.googlesource.com/c/1317049
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#57261}
Refs: 0483e9a9ab
PR-URL: https://github.com/nodejs/node/pull/24125
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Yang Guo <yangguo@chromium.org>
Reviewed-By: Gus Caplan <me@gus.host>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Refael Ackermann <refack@gmail.com>
Under the assumption that debugging is more often focused on node core
source. This setting compiles V8 with only partial optimizations,
DCHECKS, and debug symbols, so it is still very much debuggable,
but it is much faster.
It does disable SLOW_DCHECKS, but at the advice of the V8 team, those
are more important for deep V8 debugging.
Override is configurable with `./configure --v8-non-optimized-debug`.
PR-URL: https://github.com/nodejs/node/pull/23704
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Ujjwal Sharma <usharma1998@gmail.com>
Run `node_js2c` and `mkssldef` as actions and not as targets makes sure
they are run only once, just before processing the rest of `node_lib`.
This helps `make` based dependency change detection be more accurate.
Add comments with tagrget names for readability.
Use `process_outputs_as_sources` for automatic inclution of outputs.
PR-URL: https://github.com/nodejs/node/pull/23156
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
