This patch changes the order in which stack values are shown
in the stack scope. As a result, changes to the stack show up
at the end of the stack.
Bug: chromium:1043034
Change-Id: I735fc29d3957b6484589554ce046114e1b7bd9e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122987
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66884}
This is a minor cosmetic fix. Wasm opcodes are bytes, hence they should
always be printed as an even number of hexadecimal digits.
Note that currently we only print a single byte anyway, but in the
future we will want to extend this to correctly parse multi-byte
opcodes. Those will also be printed as an even number of characters
then.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I2423277b470d74c1c72cb619c2a43bb978423bc0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122025
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66883}
The asm-wasm-f32 and asm-wasm-f64 tests run through a bunch of different
constants. For the binops, they run through a cross product of the
inputs. This patch trims down the number of constants used.
The selection of constants to remove is quite arbitrary - the intial
patch introduced a lot of magic constants that look random or has some
pattern. I don't think they mean anything special, especially for f64
form since those values all fit in a f64. For f32 we still have a bunch
of values to exceed the maximum integer representable in f32.
Bug: v8:7783
Change-Id: If34b084a11acdf21b1d2933fdd0cab65be1738c9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116988
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66882}
Yet another corner case how non-deterministic timestamps slipped into
the tests.
Bug: chromium:1064900
Change-Id: I33e8b4c8141b3854b7eca5d7ad9b45b6f5130d9e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120584
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66881}
MSVC versions 19.24 and onward generate invalid code for this
function. The workaround is to deinline it. This probably costs
some performance, but is not intended to be permanent.
Bug: v8:10352
Change-Id: I8a9b8f70c77f26c8af86c679aae8c9fb8ec28cd7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118530
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66880}
Rework testMemoryGrowPreservesDataMemOp tests so that they only test the
first and last 5 offsets within the page, instead of every offset.
Slight logic change: instead of storing the value C - offset (where C is
a constant that is different for 32 and 16 memops), we store just the
value offset. This allows us to combine the logic for all 3 memops (32,
16, and 8). But we need to add a modulo so that in the 8 bit case, we
don't store a value that exceeds the maximum (the other cases will never
hit a case that exceeds the max).
Bug: v8:7783
Change-Id: Ibfdc77555ba2ca26391eba303050a03538f6012d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117633
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66879}
We were missing test cases for i16, i64, and f64. It's not super
critical, but it's also an easy addition, and helps bring coverage of
memory-tracing.cc up (close to 100% now).
Change-Id: Ib8433f8615c900d8665ccbc33e12d6fd05d51336
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2121168
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66878}
Most control structures in WebAssembly do not have a clear execution
semantics, they are more like markers. Hence the execute state, and the
change in the state, when breaking on them and stepping over them is
unclear.
Hence this CL just makes them non-breakable. If the user tries to set a
breakpoint on them, this breakpoint will automatically be propagated to
the first instruction after the respective control opcode (this is
tested for other cases in existing tests).
R=thibaudm@chromium.org
Bug: v8:10326
Change-Id: Iaf540a94789c9cbc87d23ddfb794e4b01776b49f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122017
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66876}
Make sure to call MaybeProcessSourceRanges in ParseOnBackground so that
code coverage ranges match between main thread and background compiles.
Bug: chromium:1011762
Change-Id: Ic6194083e425f4160e34a34bceb6034624cf1b9f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120540
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66872}
The top wasm frame position can be inaccurate after removing a
breakpoint and OSRing the new code. This is because we are missing the
source position which was associated with that breakpoint in the old
code. Fix this by explicitly introducing the missing source position.
R=clemensb@chromium.org
Change-Id: I0d18061c4c2411de8d2ccaaebbb4eb550a4c3160
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120591
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66871}
Now that the trace json file has changed name, update the extension
checked by the --retain=json flag in generate-runtime-callstats.py.
Bug: v8:10348
Change-Id: Ieb14b77d2d399a1246049170f289b4666658f376
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2122015
Auto-Submit: Dan Elphick <delphick@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66870}
We were sometimes stopping on a one-shot breakpoints in JS code even
though the last user action was actually a resume.
This CL fixes that clearing all stepping in JS whenever we hit a
breakpoint in wasm.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: Ie5d12bb0c9e766bcbd5ad0aa225a8b14b4d608b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120588
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66869}
Fix generate-run-benchmark to pick the trace json file now that
run_benchmark generates a different directory structure due to the
protobuf change.
Bug: v8:10348
No-Try: true
Change-Id: I4d671071db68a7a82ec542bf41bf1d9afcdb3837
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120590
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66868}
This change adds a stack scope for wasm debugging.
Currently the local scope contains both local variables as well as
the expression stack. For now, this change duplicates the information
available on stacks into the stack scope, until we have added
support for the stack scope in the DevTools front-end.
Bug: chromium:1043034
Change-Id: Ib0a07e07be7c53003526a7b1e1dbfaa1116b41ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093510
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66867}
std::atomic loads are marked as nodiscard on MSVC. Fix the warning by
feeding the load into the USE() macro.
Bug: chromium:1056170
Change-Id: I72ca42d42d268c4b961d96618250229a53709472
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120543
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66866}
For a bunch of s8x16, s16x2 and s32x4 shuffle ops (generated by
s8x16shuffle).
Bug: v8:9561
Change-Id: I0e5cd8a90edba8bc15918c0ca1dc830475db2769
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110952
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66865}
Previously OffThreadIsolates set their thread-id on construction. This
thread-id could later be used in DCHECKs, comparing it against the
current thread's id.
However, OffThreadIsolates are created on the main thread (as they need
access to the Isolate and especially Heap for initialization). So, the
thread-id was actually not the background thread's id.
Now, OffThreadIsolate has a PinToCurrentThread method which should be
called on whichever thread wants to actually use it. This pinning can
only be done once, and the OffThreadIsolate is considered invalid before
this method is called.
Bug: chromium:1011762
Change-Id: Ie9d7838152683aea2a326a4e5d1dbd59a747131f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110016
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66864}
Using the "logSourceLocation" function from protocol-test.js prints
slightly better location information for wasm, and especially much
better information for JS breakpoints. This helps understanding and
debugging these tests.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: I51c7d168d2cb19fb8469b4a2eb372c2b95650fcb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120539
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66863}
This reverts commit 0c72c71900.
Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer
Original change's description:
> Move branch inversion on ==0 into platform-agnostic reducer
>
> This change is based on a discussion from
> https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
> wherein Tobias suggested moving the folding away of ==0 operations out
> of the platform-specific instruction selectors and into the
> MachineOperatorReducer. I noticed that CommonOperatorReducer already
> handles some very similar cases, so I have tried putting the ==0 folding
> into CommonOperatorReducer instead. I'm happy to move it into
> MachineOperatorReducer if that's better; I still don't have a very good
> understanding of how roles are separated among reducers.
>
> Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#66688}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1061767
Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66862}
This adds HeapObjectHeader, a meta object that is put in front of
every managed object. HeapObjectHeader provides accessors for:
1. GCInfoIndex
2. In construction bit
3. size
4. Mark bit
Meta info is distributed among two uint16_t fields as (1.,2.) and
(3.,4.). This is convenient as the non-bit accessors (size,
GCInfoIndex) are constant during marking.
Object layout see heap-object-header.h.
Note: The current implementation does not bypass ASAN poisoning and
assumes an unpoisoned header whenever performing an access.
Bug: chromium:1056170
Change-Id: I753f15467ed5c2b22b47e64d3aa5a3c1baddf8e1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116031
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66861}
In off-thread compilation, the ParseInfo is released on the background
thread. We have to make sure to that the OffThreadParseInfoScope doesn't
try to reset its per-thread data in this case.
Bug: chromium:1011762
Change-Id: I6ddad6508cacc18f29e020e373783da64d3e4cb7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115431
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66860}
This enables the --debug-in-liftoff flag in the wasm-scope-info test.
The expected output slightly differs, because we get another breakpoint
at the end of the function body, which was actually missing before.
R=thibaudm@chromium.org
Bug: v8:10351
Change-Id: Ic2628b26591763cea17403f74fe0f6d935633e6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120535
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66859}
A StringView is pretty light, so this should be similar to
how absl::string_view is typically used, e.g. see the guidance here:
https://github.com/abseil/abseil-cpp/blob/master/absl/strings/string_view.h
I suspect this reasoning holds even though StringView (defined
just above StringBuffer in v8-inspector.h) carries an additional bool.
This yields a small simplification of the StringBuffer implementations.
Change-Id: I03f850049afe2327913070838f39649fcdfa6fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045110
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66858}
MSVC 19.25 complains about signbit being ambiguous between
signbit(float) and signbit(double) overloads when called with an int8_t.
To remove the ambiguity, cast to a double.
Change-Id: I698f05eed9248eef493bbe46b75fcd07e37e2a05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2118510
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Richard Townsend <richard.townsend@arm.com>
Cr-Commit-Position: refs/heads/master@{#66856}
For some input types containing -0 but not +0, the result type of
NumberMin and NumberMax would unnecessarily include +0. However, for
some larger inputs, the result type would not include the spurious +0,
thus breaking monotonicity.
The CL fixes this and addresses a TODO as well.
Bug: chromium:1063661
Change-Id: Icd56d6102fbea12a2d96aa063a803b1052c714b8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116199
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66854}
Add LocalHandleScope to allow for local handles in LocalHeaps
(background threads). This class is similar to HandleScope which still
needs to be used on the main thread. When performing a GC, the main
thread halts all background threads at a safepoint such that it can
safely iterate their roots.
Bug: v8:10315
Change-Id: Id8f5d54cc2535e004081ccdef15dc03a39b2d0f0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111218
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66853}
A StepOver at a return (either explicit return instruction, or implicit
return at the end of the function) should stop again in the caller
frame.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I313e6b612ac52e73b33ef07c6da1ced2aa0db600
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2110250
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66852}
This fixes issues with replacing the return address of deeper (non-top)
wasm frames, i.e. frames which are at a call position. The replaced
address should also point after the call in the new code, so we don't
execute the same call again.
This is achieved by using slightly different encodings for breakpoint
positions and other (wasm instruction) positions. Breakpoints set
{is_instruction} to {false} in the source position table entry, whereas
usual wasm instruction set it to {true}.
Also, during stack walking for OSR, we remember whether we want to OSR
to the position before the instruction (if it's the top frame), or after
the call instruction (if it's deeper in the stack). We then use the
{is_instruction} predicate to find the right location.
R=thibaudm@chromium.org
Bug: v8:10321
Change-Id: I73212a7532c6ecf4c82bde76fe4059c8203e422c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116206
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66850}
As discussed offline, adding myself to OWNERS for the C++ GC, handles,
and Blink embedding issues in general.
Bug: chromium:1056170
Change-Id: Iff6a9f119000c04b40fb12b70f56d9bab7e32b43
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116204
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66849}
Rework the testMemoryGrowReadWrite and testMemoryGrowZeroInitialSize
tests. Combine the different sized tests (32, 16, 8 bit integers) into a
single base tests, taking in function arguments to specify which
load/store function to call from the module exports.
Also reduced the number of checks made in each test. Previously the test
was asserting on every single valid offset. Now it checks the first 5
and the last 5 of each page of memory. From a quick local test using
`time`, it speeds up this test on x64 from ~40s to ~20s.
There is more work to be done: there are other tests below that also
assert on each offset, we can change those in a future patch.
The goal is to be able to run this on arm simulators
sufficiently quickly, and not require to mark this test as slow.
Bug: v8:7783
Change-Id: I2b17cf1811de6c26332d7e8f91efbbac3e89f6e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116601
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66848}
GCInfo and its related infrastructure is used to record information
about types. Currently, we store finalization and vtable information.
Future changes will introduce naming and tracing, similar to Oilpan in
Blink.
Information is stored in a process-wide global table that is
maintained at runtime. For static builds such information can be
recorded in the binary without the runtime overhead which is future
work.
This ports `third_party/blink/renderer/platform/heap/gc_info.{h,cc}`
on a semantic level. In addition to adjusting to V8's needs, we also
re-commit the already filled parts of the info table as read-only when
possible, making it harder to override type information.
Bug: chromium:1056170
Change-Id: Ib01eb24e6f8a94a4a647efde7af37689f8c20ba2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111214
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66847}
This DCHECK can fail because we currently pass arbitrary types
in the typer unittests. Changing the tests is complicated by the
fact that the compiler makes heavy use of type Any and we don't want
to lose test coverage for that. Hence for now I just remove the DCHECK.
I'm working on a follow-up CL but that one will not be able to land any
time soon due to the current restrictions.
Bug: v8:10338
Change-Id: Ibb3bb44e41b76cd91b190af184f6345cdf97d49d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116203
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66846}
Architecture judgement functions like ‘IsMipsArchVariant’, ‘IsFpxxMode’
used to be macro functions, which may cause ‘unreachable-code’ error if
they are used as condition expressions for ‘if’ statements.
This CL change them to constexpr functions to avoid it.
Change-Id: Id3d8473920711a05abc39265c88e91cc1cb7d5e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2115833
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Auto-Submit: Zhao Jiazhong <zhaojiazhong-hf@loongson.cn>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66843}
We have similar logic in place when allocating wasm memory fails. For
growing, we also need to hard-abort the program, because it would cause
observable differences in program behaviour otherwise.
R=ahaas@chromium.org, machenbach@chromium.org
Bug: chromium:1063951
Change-Id: I98f3b5364100900fce0e6553a347155a39923ca6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2116036
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66842}
