v8/BUILD.gn

7379 lines
246 KiB
Plaintext
Raw Normal View History

# Copyright 2014 The Chromium Authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
import("//build/config/android/config.gni")
import("//build/config/arm.gni")
import("//build/config/dcheck_always_on.gni")
import("//build/config/host_byteorder.gni")
import("//build/config/mips.gni")
import("//build/config/sanitizers/sanitizers.gni")
import("//build_overrides/build.gni")
if (is_android) {
import("//build/config/android/rules.gni")
}
import("gni/snapshot_toolchain.gni")
import("gni/v8.gni")
# Specifies if the target build is a simulator build. Comparing target cpu
# with v8 target cpu to not affect simulator builds for making cross-compile
# snapshots.
target_is_simulator = (target_cpu != v8_target_cpu && !v8_multi_arch_build) ||
(current_cpu != v8_current_cpu && v8_multi_arch_build)
# For faster Windows builds. See https://crbug.com/v8/8475.
emit_builtins_as_inline_asm = is_win && is_clang
declare_args() {
# Print to stdout on Android.
v8_android_log_stdout = false
# Dynamically set an additional dependency from v8/custom_deps.
v8_custom_deps = ""
# Turns on all V8 debug features. Enables running V8 in a pseudo debug mode
# within a release Chrome.
v8_enable_debugging_features = is_debug
# Sets -DV8_ENABLE_FUTURE.
v8_enable_future = false
# Sets -DENABLE_SYSTEM_INSTRUMENTATION. Enables OS-dependent event tracing
v8_enable_system_instrumentation = (is_win || is_mac) && !v8_use_perfetto
Step 1 (of 3-ish): Basic ETW Instrumentation in V8 Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
2021-01-05 18:43:34 +00:00
# Sets -DV8_ENABLE_ETW_STACK_WALKING. Enables ETW Stack Walking
v8_enable_etw_stack_walking = is_win
Step 1 (of 3-ish): Basic ETW Instrumentation in V8 Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
2021-01-05 18:43:34 +00:00
# Sets the GUID for the ETW provider
v8_etw_guid = ""
# Sets -DVERIFY_HEAP.
v8_enable_verify_heap = ""
# Sets -DVERIFY_PREDICTABLE
v8_enable_verify_predictable = false
# Enable compiler warnings when using V8_DEPRECATED apis.
v8_deprecation_warnings = true
# Enable compiler warnings when using V8_DEPRECATE_SOON apis.
v8_imminent_deprecation_warnings = true
# Embeds the given script into the snapshot.
v8_embed_script = ""
# Allows the embedder to add a custom suffix to the version string.
v8_embedder_string = ""
# Sets -dENABLE_DISASSEMBLER.
v8_enable_disassembler = ""
# Sets the number of internal fields on promise objects.
v8_promise_internal_field_count = 0
# Sets -dENABLE_GDB_JIT_INTERFACE.
v8_enable_gdbjit = ""
# Sets -dENABLE_VTUNE_JIT_INTERFACE.
v8_enable_vtunejit = false
Reland "Support Intel VTune ITT API" This is a reland of 5f5b4b04078a5da96b4c8244241cf73dc928f721 Original change's description: > Support Intel VTune ITT API > > Add VTune domain support extension to use VTune Domain/Task API and > tagging trace data for particular JS code block. > > How to use: > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient > file to download intel/ittapi by 'gclient sync' > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true' > 3. Run d8 with flag '--enable-vtune-domain-support' > > The Vtune Domain/Task API can be invoked from JS to mark JS code block. > You can mark the start of a JS task by > vtunedomainmark(domain_name, task_name, "start") > and the end of a task by > vtunedomainmark(domain_name, task_name, "end") > Tasks can nest. > > The VTune API (ittapi) is integrated as an external third party library > while the v8_vtune_jit also relies on the VTune ittapi. We have another > patch almost ready which refactors the v8_vtune_jit related code to > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit > code after this patch stabilized and landed. > > > Contributed by fanchen.kong@intel.com > > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490 > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65409} Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65478}
2019-12-14 08:46:38 +00:00
# Sets -dENABLE_VTUNE_TRACEMARK.
v8_enable_vtunetracemark = false
# Sets -dENABLE_HUGEPAGE
v8_enable_hugepage = false
# Sets -dENABLE_HANDLE_ZAPPING.
v8_enable_handle_zapping = is_asan || is_debug
# Enable slow dchecks.
v8_enable_slow_dchecks = false
# Enable fast mksnapshot runs.
v8_enable_fast_mksnapshot = false
# Optimize code for Torque executable, even during a debug build.
v8_enable_fast_torque = ""
# Enable the registration of unwinding info for Windows x64 and ARM64.
Reland "Generate unwind info on Win/x64 by default" The original CL title was updated to reflect CL contents. The --win64-unwinding-info flag still exists but it is set by default. This is a reland of efd8c2d9752c4206966dfd72e4794e025b9843e1 Original change's description: > Remove --win64-unwinding-info flag and always generate unwind info on Win/x64 > > The generation of unwind info to enable stack walking on Windows/x64 > (https://chromium-review.googlesource.com/c/v8/v8/+/1469329) was implemented > behind a temporary flag, in order to coordinate these changes with the > corresponding changes in Chromium. > > The required changes to Chromium > (https://chromium-review.googlesource.com/c/chromium/src/+/1474703) have also > been merged, so we can now remove the flag and enable the generation of stack > unwinding info by default on Windows/x64. > > Bug: v8:3598 > Change-Id: I88814aaeabecc007f5262227aa0681a1d16156d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1573138 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#61020} Bug: v8:3598, chromium:958035 Change-Id: Ie53b39f3bb31567797a61e5110685284c266c1f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1599596 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#61368}
2019-04-24 22:01:00 +00:00
v8_win64_unwinding_info = true
Reland "V8 x64 backend doesn't emit ABI compliant stack frames" This is a reland of 3cda21de77d098a612eadf44d504b188a599c5f0 Original change's description: > V8 x64 backend doesn't emit ABI compliant stack frames > > On 64 bit Windows, the OS stack walking does not work because the V8 x64 > backend doesn't emit unwinding info and also because it doesn't emit ABI > compliant stack frames. See > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit > for more details. > > This problem can be fixed by observing that V8 frames usually all have the same > prolog and epilog: > > push rbp, > mov rbp, rsp > ... > pop rbp > ret N > > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows > should walk through V8 frames. Furthermore, since V8 Code objects are all > allocated in the same code-range for an Isolate, it is possible to register a > single PDATA/XDATA entry to cover stack walking for all the code generated > inside that code-range. > > This PR contains changes required to enable stack walking on Win64: > > EmbeddedFileWriter now adds assembler directives to the builtins > snapshot source file (embedded.cc) to emit additional entries in the .pdata and > in the .xdata section of the V8 executable. This takes care of stack walking > for embedded builtins. (The case of non-embedded builtins is not supported). > The x64 Assembler has been modified to collect the information required to emit > this unwind info for builtins. > > Stack walking for jitted code is handled is Isolate.cpp, by registering > dynamically PDATA/XDATA for the whole code-range address space every time a new > Isolate is initialized, and by unregistering them when the Isolate is > destroyed. > > Stack walking for WASM jitted code is handled is the same way in > wasm::NativeModule (wasm/wasm-code-manager.cpp). > > It is important to note that Crashpad and Breakpad are already registering > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded > builtins). Since it is not possible to register multiple PDATA entries for the > same address range, a new function is added to the V8 API: > SetUnhandledExceptionCallback() can be used by an embedder to register its own > unhandled exception handler for exceptions that arise in v8-generated code. > V8 embedders should be modified accordingly (code for this is in a separate PR > in the Chromium repository: > https://chromium-review.googlesource.com/c/chromium/src/+/1474703). > > All these changes are experimental, behind: > > the 'v8_win64_unwinding_info' build flag, and > the '--win64-unwinding-info' runtime flag. > > Bug: v8:3598 > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#60330} Bug: v8:3598 Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60581}
2019-04-01 21:43:23 +00:00
Reland "Reland "Reland "[code-comments] Put code comments into the code object""" This is a reland of 9c0a48580bc820d93a16f8914281a7359beb2a7a Original change's description: > Reland "Reland "[code-comments] Put code comments into the code object"" > > This is a reland of ed3d647284538e9d6f013ebf2c460697aa06a5df > > This reland fixes that padding at the end of Wasm instruction streams > triggered asserts in the code printer. > > Original change's description: > > Reland "[code-comments] Put code comments into the code object" > > > > This is a reland of e774cffe2bd3f00332209d4d5695221963888c96 > > > > This reland disables a test as v8:8548 is blocking it, which was > > broken by a recent CL. CQ did not catch this because the merge-base > > CQ used did not yet contain the CL that caused v8:8548. > > > > Original change's description: > > > [code-comments] Put code comments into the code object > > > > > > Code comments in the snapshot can now be enabled with gn > > > arg 'v8_enable_snapshot_code_comments' > > > > > > Bug: v8:7989 > > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3 > > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173 > > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#58020} > > > > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org > > > > Bug: v8:7989, v8:8548 > > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9 > > Reviewed-on: https://chromium-review.googlesource.com/c/1361166 > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58028} > > Bug: v8:7989, v8:8548 > Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d > Reviewed-on: https://chromium-review.googlesource.com/c/1371784 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58221} TBR=jgruber@chromium.org,mstarzinger@chromium.org Bug: v8:7989, v8:8548, v8:8593 Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b Reviewed-on: https://chromium-review.googlesource.com/c/1375919 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58232}
2018-12-13 19:30:56 +00:00
# Enable code comments for builtins in the snapshot (impacts performance).
# This also enables v8_code_comments.
Reland "Reland "Reland "[code-comments] Put code comments into the code object""" This is a reland of 9c0a48580bc820d93a16f8914281a7359beb2a7a Original change's description: > Reland "Reland "[code-comments] Put code comments into the code object"" > > This is a reland of ed3d647284538e9d6f013ebf2c460697aa06a5df > > This reland fixes that padding at the end of Wasm instruction streams > triggered asserts in the code printer. > > Original change's description: > > Reland "[code-comments] Put code comments into the code object" > > > > This is a reland of e774cffe2bd3f00332209d4d5695221963888c96 > > > > This reland disables a test as v8:8548 is blocking it, which was > > broken by a recent CL. CQ did not catch this because the merge-base > > CQ used did not yet contain the CL that caused v8:8548. > > > > Original change's description: > > > [code-comments] Put code comments into the code object > > > > > > Code comments in the snapshot can now be enabled with gn > > > arg 'v8_enable_snapshot_code_comments' > > > > > > Bug: v8:7989 > > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3 > > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173 > > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#58020} > > > > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org > > > > Bug: v8:7989, v8:8548 > > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9 > > Reviewed-on: https://chromium-review.googlesource.com/c/1361166 > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58028} > > Bug: v8:7989, v8:8548 > Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d > Reviewed-on: https://chromium-review.googlesource.com/c/1371784 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58221} TBR=jgruber@chromium.org,mstarzinger@chromium.org Bug: v8:7989, v8:8548, v8:8593 Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b Reviewed-on: https://chromium-review.googlesource.com/c/1375919 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58232}
2018-12-13 19:30:56 +00:00
v8_enable_snapshot_code_comments = false
# Allow runtime-enabled code comments (with --code-comments). Enabled by
# default in debug builds.
# Sets -dV8_CODE_COMMENTS
v8_code_comments = ""
# Allow runtime-enabled debug code (with --debug-code). Enabled by default in
# debug builds.
# Sets -dV8_ENABLE_DEBUG_CODE
v8_enable_debug_code = ""
# Enable native counters from the snapshot (impacts performance, sets
# -dV8_SNAPSHOT_NATIVE_CODE_COUNTERS).
# This option will generate extra code in the snapshot to increment counters,
# as per the --native-code-counters flag.
v8_enable_snapshot_native_code_counters = ""
# Use pre-generated static root pointer values from static-roots.h.
v8_enable_static_roots = false
# Enable code-generation-time checking of types in the CodeStubAssembler.
v8_enable_verify_csa = false
# Enable pointer compression (sets -dV8_COMPRESS_POINTERS).
v8_enable_pointer_compression = ""
v8_enable_pointer_compression_shared_cage = ""
v8_enable_31bit_smis_on_64bit_arch = false
# Sets -dOBJECT_PRINT.
v8_enable_object_print = ""
# Sets -dV8_TRACE_MAPS.
v8_enable_trace_maps = ""
# Sets -dV8_ENABLE_CHECKS.
v8_enable_v8_checks = ""
# Sets -dV8_TRACE_UNOPTIMIZED.
v8_enable_trace_unoptimized = ""
v8_enable_trace_ignition = false
v8_enable_trace_baseline_exec = false
# Sets -dV8_TRACE_FEEDBACK_UPDATES.
v8_enable_trace_feedback_updates = false
# Sets -dV8_ATOMIC_OBJECT_FIELD_WRITES and turns all field write operations
# into relaxed atomic operations.
v8_enable_atomic_object_field_writes = ""
# Controls the default value of v8_enable_concurrent_marking_state. See the
# default setting code below.
v8_enable_concurrent_marking = true
# Sets -dV8_IGNITION_DISPATCH_COUNTING.
# Enables counting frequencies of bytecode dispatches. After building in this
# configuration, subsequent runs of d8 can output frequencies for each pair
# of (current, next) bytecode instructions executed if you specify
# --trace-ignition-dispatches-output-file, or can generate a JS object with
# those frequencies if you run with --expose-ignition-statistics and call the
# extension function getIgnitionDispatchCounters().
v8_enable_ignition_dispatch_counting = false
[diagnostics] Support --turbo-profiling for builtins Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
2020-05-21 15:51:40 +00:00
# Runs mksnapshot with --turbo-profiling. After building in this
# configuration, any subsequent run of d8 will output information about usage
# of basic blocks in builtins.
[diagnostics] Support --turbo-profiling for builtins Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
2020-05-21 15:51:40 +00:00
v8_enable_builtins_profiling = false
# Runs mksnapshot with --turbo-profiling-verbose. After building in this
# configuration, any subsequent run of d8 will output information about usage
# of basic blocks in builtins, including the schedule and disassembly of all
# used builtins.
v8_enable_builtins_profiling_verbose = false
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
# Provides the given V8 log file as an input to mksnapshot, where it can be
# used for profile-guided optimization of builtins.
#
# To do profile-guided optimizations of builtins:
# 1. Build with v8_enable_builtins_profiling = true
# 2. Run your chosen workload with the --turbo-profiling-output flag.
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
# For Chrome, the invocation might look like this:
# chrome --no-sandbox --disable-extensions
# --js-flags="--turbo-profiling-output=v8.builtins.pgo"
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
# "http://localhost/test-suite"
# 3. Run tools/builtins-pgo/get_hints.py to produce the branch hints,
# selecting min_count and threshold_ratio as you wish.
# 4. Optionally repeat steps 2-3 for additional workloads, and use
# tools/builtins-pgo/combine_hints.py to combine the hints produced in
# step 3 into a single file.
# 5. Build again with v8_builtins_profiling_log_file set to the file created
# in step 3 or 4.
v8_builtins_profiling_log_file = "default"
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
# Enables various testing features.
v8_enable_test_features = ""
# Enable short builtins call instruction sequences by un-embedding builtins.
# Sets -dV8_SHORT_BUILTIN_CALLS
v8_enable_short_builtin_calls = ""
# Enable support for external code range relative to the pointer compression
# cage.
# Sets -dV8_EXTERNAL_CODE_SPACE
v8_enable_external_code_space = ""
# Enable the Maglev compiler.
# Sets -dV8_ENABLE_MAGLEV
v8_enable_maglev = ""
# With post mortem support enabled, metadata is embedded into libv8 that
# describes various parameters of the VM for use by debuggers. See
# tools/gen-postmortem-metadata.py for details.
v8_postmortem_support = false
# Use Siphash as added protection against hash flooding attacks.
v8_use_siphash = false
# Switches off inlining in V8.
v8_no_inline = false
# Override OS page size when generating snapshot
v8_os_page_size = "0"
# Similar to vfp but on MIPS.
v8_can_use_fpu_instructions = true
# Similar to the ARM hard float ABI but on MIPS.
v8_use_mips_abi_hardfloat = true
# Controls the threshold for on-heap/off-heap Typed Arrays.
v8_typed_array_max_size_in_heap = 64
v8_enable_gdbjit = ((v8_current_cpu == "x86" || v8_current_cpu == "x64") &&
(is_linux || is_chromeos || is_mac)) ||
(v8_current_cpu == "ppc64" && (is_linux || is_chromeos))
# Check that each header can be included in isolation (requires also
# setting the "check_v8_header_includes" gclient variable to run a
# specific hook).
v8_check_header_includes = false
# Enable sharing read-only space across isolates.
# Sets -DV8_SHARED_RO_HEAP.
v8_enable_shared_ro_heap = ""
# Enable lazy source positions by default.
v8_enable_lazy_source_positions = true
# Enable third party HEAP library
v8_enable_third_party_heap = false
# Libaries used by third party heap
v8_third_party_heap_libs = []
# Source code used by third party heap
v8_third_party_heap_files = []
# Disable write barriers when GCs are non-incremental and
# heap has single generation.
v8_disable_write_barriers = false
# Ensure that write barriers are always used.
# Useful for debugging purposes.
v8_enable_unconditional_write_barriers = false
# Redirect allocation in young generation so that there will be
# only one single generation.
v8_enable_single_generation = ""
# Use token threaded dispatch for the regular expression interpreter.
# Use switch-based dispatch if this is false
v8_enable_regexp_interpreter_threaded_dispatch = true
# Enable additional targets necessary for verification of torque
# file generation
v8_verify_torque_generation_invariance = false
# Generate comments describing the Torque intermediate representation.
v8_annotate_torque_ir = false
# Enable snapshot compression (enabled by default for desktop) devices.
v8_enable_snapshot_compression =
target_os == "android" || target_os == "chromeos" ||
target_os == "fuchsia"
Reland "[arm64] Protect return addresses stored on stack" This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df 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/+/2051958 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#66254}
2020-02-12 11:45:31 +00:00
# Enable control-flow integrity features, such as pointer authentication for
# ARM64. Enable it by default for simulator builds and when native code
# supports it as well.
v8_control_flow_integrity =
v8_current_cpu == "arm64" &&
(target_is_simulator || arm_control_flow_integrity != "none")
# Enable heap reservation of size 4GB. Only possible for 64bit archs.
cppgc_enable_caged_heap =
v8_current_cpu == "x64" || v8_current_cpu == "arm64" ||
v8_current_cpu == "loong64"
# Enables additional heap verification phases and checks.
cppgc_enable_verify_heap = ""
# Enable allocations during prefinalizer invocations.
cppgc_allow_allocations_in_prefinalizers = false
# Enable V8 zone compression experimental feature.
# Sets -DV8_COMPRESS_ZONES.
v8_enable_zone_compression = ""
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
# Enable the experimental V8 sandbox.
# Sets -DV8_ENABLE_SANDBOX.
v8_enable_sandbox = ""
# Expose the memory corruption API to JavaScript. Useful for testing the sandbox.
# WARNING This will expose builtins that (by design) cause memory corruption.
# Sets -DV8_EXPOSE_MEMORY_CORRUPTION_API
v8_expose_memory_corruption_api = false
# Experimental feature for collecting per-class zone memory stats.
# Requires use_rtti = true
v8_enable_precise_zone_stats = false
# Experimental feature that uses SwissNameDictionary instead of NameDictionary
# as the backing store for all dictionary mode objects.
v8_enable_swiss_name_dictionary = false
# If enabled then macro definitions that are used in externally visible
# header files are placed in a separate header file v8-gn.h.
Revert "[build] Enable external flag header with defines" This reverts commit 1370b29e75e6a51e31f728e8f6f8f345badf67a2. Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409. Original change's description: > [build] Enable external flag header with defines > > Due to some unusual build failures on some trybots, > v8_generate_external_defines_header was reverted to false. This turns it > back on but changes the behaviour so that defines are added to the > command line as well as to the header. Because the generated header > checks that flags that should be unset are actually unset and flags that > should be set are either unset or set to 1, this will cause build > failures on many types of mismatches, although it will not detect where a > flag is not set on the command line when it is set by the header. > > If no further failures show up with this, the hybrid part can be removed > and the v8-gn.h header can stand on its own. > > Bug: v8:11292, v8:11341 > Change-Id: I1deeeebec58f79607e68a28f808649e884810923 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72327} TBR=mlippautz@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:11292 Bug: v8:11341 Change-Id: I6cf57014ef8be73c286ad9c5ebf597915f183717 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695400 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72748}
2021-02-15 13:26:12 +00:00
v8_generate_external_defines_header = false
# Experimental feature for tracking constness of properties in non-global
# dictionaries. Enabling this also always keeps prototypes in dict mode,
# meaning that they are not switched to fast mode.
# Sets -DV8_DICT_PROPERTY_CONST_TRACKING
v8_dict_property_const_tracking = false
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
# Enable map packing & unpacking (sets -dV8_MAP_PACKING).
v8_enable_map_packing = false
# Allow for JS promise hooks (instead of just C++).
v8_enable_javascript_promise_hooks = false
# Enable allocation folding globally (sets -dV8_ALLOCATION_FOLDING).
# When it's disabled, the --turbo-allocation-folding runtime flag will be ignored.
v8_enable_allocation_folding = true
# Enable runtime verification of heap snapshots produced for devtools.
v8_enable_heap_snapshot_verify = ""
# Enable global allocation site tracking.
v8_allocation_site_tracking = true
# TODO(cbruni, v8:12302): Remove once API is migrated
# Enable legacy mode for ScriptOrModule's lifetime. By default it's a
# temporary object, if enabled it will be kept alive by the parent Script.
# This is only used by nodejs.
v8_scriptormodule_legacy_lifetime = false
# Change code emission and runtime features to be CET shadow-stack compliant
# (incomplete and experimental).
v8_enable_cet_shadow_stack = false
# Get VMEX priviledge at startup.
# It allows to run V8 without "deprecated-ambient-replace-as-executable".
# Sets -DV8_USE_VMEX_RESOURCE.
# TODO(victorgomes): Remove this flag once Chormium no longer needs
# the deprecated feature.
v8_fuchsia_use_vmex_resource = is_fuchsia && !build_with_chromium
# Enables pointer compression for 8GB heaps.
# Sets -DV8_COMPRESS_POINTERS_8GB.
v8_enable_pointer_compression_8gb = ""
# Compile V8 using zlib as dependency.
# Sets -DV8_USE_ZLIB
v8_use_zlib = true
# Make ValueDeserializer crash if the data to deserialize is invalid.
v8_value_deserializer_hard_fail = false
}
# Derived defaults.
if (cppgc_enable_verify_heap == "") {
cppgc_enable_verify_heap = v8_enable_debugging_features || dcheck_always_on
}
if (v8_enable_verify_heap == "") {
v8_enable_verify_heap = v8_enable_debugging_features
}
if (v8_enable_object_print == "") {
v8_enable_object_print = v8_enable_debugging_features
}
if (v8_enable_disassembler == "") {
v8_enable_disassembler = v8_enable_debugging_features
}
if (v8_enable_trace_maps == "") {
v8_enable_trace_maps = v8_enable_debugging_features
}
if (v8_enable_test_features == "") {
Revert "Reland "[build] Add V8-specific dcheck_always_on"" This reverts commit 67960ba110803b053a772eff7aeac6c5d2f23143. Reason for revert: This has been properly fixed by https://crrev.com/c/3053740. Now dcheck_always_on already defaults to false for subprojects like V8 and no other switch is required. The switch didn't fully work anyways due to https://crbug.com/1231890. Original change's description: > Reland "[build] Add V8-specific dcheck_always_on" > > This is a reland of cecc666f4d681dc6eca7c9a65ff9da05ea42f1e3 > > Depends on: > https://crrev.com/c/3043611 > > Original change's description: > > [build] Add V8-specific dcheck_always_on > > > > This makes the V8 dcheck control independent of Chromium's and > > prepares switching Chromium's default behavior without affecting V8 > > developers or builders. > > > > Preparation for: https://crrev.com/c/2893204 > > > > Bug: chromium:1225701 > > Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75827} > > Bug: chromium:1225701 > Change-Id: I56568b78592addba01793d2d14f768c9ee10103d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041670 > Reviewed-by: Liviu Rau <liviurau@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75839} Bug: chromium:1225701, chromium:1231890 Change-Id: I7e27f5774d8e162977f30f685da4b15dadcc1084 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055294 Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#75935}
2021-07-27 06:41:14 +00:00
v8_enable_test_features = v8_enable_debugging_features || dcheck_always_on
}
if (v8_enable_v8_checks == "") {
v8_enable_v8_checks = v8_enable_debugging_features
}
if (v8_enable_heap_snapshot_verify == "") {
v8_enable_heap_snapshot_verify =
v8_enable_debugging_features || dcheck_always_on
}
if (v8_enable_snapshot_code_comments) {
assert(v8_code_comments == true || v8_code_comments == "",
"v8_enable_snapshot_code_comments conflicts with v8_code_comments.")
v8_code_comments = true
} else if (v8_code_comments == "") {
v8_code_comments = v8_enable_debugging_features
}
if (v8_enable_debug_code == "") {
v8_enable_debug_code = v8_enable_debugging_features
}
if (v8_enable_snapshot_native_code_counters == "") {
v8_enable_snapshot_native_code_counters = v8_enable_debugging_features
}
if (v8_enable_pointer_compression == "") {
v8_enable_pointer_compression =
v8_current_cpu == "arm64" || v8_current_cpu == "x64"
}
# Toggle pointer compression for correctness fuzzing when building the
# clang_x64_pointer_compression toolchain. We'll correctness-compare the
# default build with the clang_x64_pointer_compression build.
if (v8_multi_arch_build &&
rebase_path(get_label_info(":d8", "root_out_dir"), root_build_dir) ==
"clang_x64_pointer_compression") {
v8_enable_pointer_compression = !v8_enable_pointer_compression
}
# Ensure the sandbox is on/off in the same way as pointer compression for
# correctness fuzzing builds.
if (v8_multi_arch_build) {
v8_enable_sandbox = v8_enable_pointer_compression
}
if (v8_enable_pointer_compression_shared_cage == "") {
Reland^4 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" This is a reland of 8b74fd45909f293d751cf926af00974b0ef86c1e Changes since revert: - Reverted a61aa4919ff7e9c14e8e47cdb447dd48913526dc for not fixing the jitless toggling issue on Chromium Win64 - Fix jitless toggling on Win64 by checking FLAG_jitless in EmbeddedDataWithMaybeRemappedEmbeddedBuiltins Original change's description: > Reland^3 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64"" > > This is a reland of 054ff044bc09696ab5dcc4fce4d0a406e6935ea9 > > Change since revert: > > - Remove assignment to FLAG_enable_short_builtins in test since > it's write-once in CFI. > > Original change's description: > > Reland^2 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" > > > > This is a reland of 1f504c36da9bab622072d65f80bbf819576c7d3f > > > > Changes since revert: > > > > - Removed disabling of RO heap sharing when --stress-snapshot is passed; > > was fixed by f4a6c628c9ac09fea8d367e41dc53f80564ffed5 > > - Fixed crashing tests that caused revert separately in > > a61aa4919ff7e9c14e8e47cdb447dd48913526dc > > > > Original change's description: > > > > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64 > > > > > > > > Reviewed-on: > > > https://chromium-review.googlesource.com/c/v8/v8/+/2873226 > > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#74422} > > > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855 > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > Reviewed-by: Adam Klein <adamk@chromium.org> > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > Reviewed-by: Dan Elphick <delphick@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#74448} > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460 > > Reviewed-by: Adam Klein <adamk@chromium.org> > > Commit-Queue: Shu-yu Guo <syg@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#74546} > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893567 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74548} TBR=ishell@chromium.org Bug: v8:11460 Change-Id: Ied925de5f886a906b1ca178365aee73155e679cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891697 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74560}
2021-05-13 22:31:02 +00:00
v8_enable_pointer_compression_shared_cage = v8_enable_pointer_compression
}
if (v8_enable_pointer_compression_8gb == "") {
v8_enable_pointer_compression_8gb = false
}
if (v8_enable_fast_torque == "") {
v8_enable_fast_torque = v8_enable_fast_mksnapshot
}
if (v8_enable_zone_compression == "") {
v8_enable_zone_compression = false
}
if (v8_enable_short_builtin_calls == "") {
v8_enable_short_builtin_calls =
v8_current_cpu == "x64" || v8_current_cpu == "arm64"
}
if (v8_enable_external_code_space == "") {
v8_enable_external_code_space =
v8_enable_pointer_compression &&
(v8_current_cpu == "x64" ||
(target_os != "fuchsia" && v8_current_cpu == "arm64"))
}
if (v8_enable_maglev == "") {
v8_enable_maglev = v8_current_cpu == "x64" && v8_enable_pointer_compression
}
if (v8_builtins_profiling_log_file == "default") {
v8_builtins_profiling_log_file = ""
# Don't use existing profile when
# * generating a new one (i.e. v8_enable_builtins_profiling),
# * is_debug or dcheck_always_on because they add more checks to the
# builtins control flow which we don't want to generate,
# * v8_enable_webassembly because it changes the set of opcodes which affects
# graphs hashes,
# * !is_clang because it might affect argument evaluation order, which
# makes node IDs not predictable for subgraphs like Op1(Op2(), Op3()) and
# as a result different graph hash.
if (!v8_enable_builtins_profiling && is_clang && !is_debug &&
!dcheck_always_on && v8_enable_webassembly) {
if ((v8_current_cpu == "x64" || v8_current_cpu == "arm64") &&
v8_enable_pointer_compression && v8_enable_external_code_space) {
# Note, currently x64 profile can be applied to arm64 but not the other
# way round.
v8_builtins_profiling_log_file = "tools/builtins-pgo/x64.profile"
} else if (v8_current_cpu == "x86" || v8_current_cpu == "arm") {
# Note, x86 profile can be applied to arm but not the other way round.
v8_builtins_profiling_log_file = "tools/builtins-pgo/x86.profile"
}
}
}
if (v8_enable_single_generation == "") {
v8_enable_single_generation = v8_disable_write_barriers
}
if (v8_enable_atomic_object_field_writes == "") {
v8_enable_atomic_object_field_writes = v8_enable_concurrent_marking
}
if (v8_enable_third_party_heap) {
v8_disable_write_barriers = true
v8_enable_single_generation = true
v8_enable_shared_ro_heap = false
v8_enable_pointer_compression = false
v8_enable_pointer_compression_shared_cage = false
v8_enable_allocation_folding = false
}
if (v8_enable_single_generation) {
v8_allocation_site_tracking = false
}
assert(!v8_enable_concurrent_marking || v8_enable_atomic_object_field_writes,
"Concurrent marking requires atomic object field writes.")
if (v8_enable_trace_unoptimized == "") {
v8_enable_trace_unoptimized =
v8_enable_trace_ignition || v8_enable_trace_baseline_exec
}
assert(!v8_enable_trace_ignition || v8_enable_trace_unoptimized,
"Ignition tracing requires unoptimized tracing to be enabled.")
assert(!v8_enable_trace_baseline_exec || v8_enable_trace_unoptimized,
"Baseline tracing requires unoptimized tracing to be enabled.")
if (v8_enable_short_builtin_calls &&
(!v8_enable_pointer_compression && v8_current_cpu != "x64")) {
# Disable short calls when pointer compression is not enabled, except x64,
# where short builtin calls can still be enabled if the code range is
# guaranteed to be close enough to embedded builtins.
v8_enable_short_builtin_calls = false
}
if (v8_enable_shared_ro_heap == "") {
v8_enable_shared_ro_heap = !v8_enable_pointer_compression ||
v8_enable_pointer_compression_shared_cage
}
if (v8_enable_sandbox == "") {
# TODO(saelo, v8:11880) remove dependency on v8_enable_external_code_space
# once that is enabled everywhere by default.
# TODO(chromium:1325784) the sandbox is not currently supported in Chromium
# on Fuchsia.
v8_enable_sandbox = v8_enable_pointer_compression_shared_cage &&
v8_enable_external_code_space && target_os != "fuchsia"
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
}
if (v8_enable_static_roots == "") {
# Static roots are only valid for builds with pointer compression and a
# shared ro heap. Also, non-wasm and non-i18n builds have fewer read-only
# roots.
v8_enable_static_roots =
v8_enable_pointer_compression && v8_enable_shared_ro_heap &&
v8_enable_pointer_compression_shared_cage && v8_enable_webassembly &&
v8_enable_i18n_support
}
assert(!v8_enable_static_roots ||
(v8_enable_pointer_compression && v8_enable_shared_ro_heap &&
v8_enable_pointer_compression_shared_cage &&
v8_enable_webassembly && v8_enable_i18n_support),
"Trying to enable static roots in a configuration that is not supported")
assert(!v8_disable_write_barriers || v8_enable_single_generation,
"Disabling write barriers works only with single generation")
Reland "[arm64] Protect return addresses stored on stack" This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df 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/+/2051958 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#66254}
2020-02-12 11:45:31 +00:00
assert(v8_current_cpu == "arm64" || !v8_control_flow_integrity,
"Control-flow integrity is only supported on arm64")
Reland^4 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" This is a reland of 8b74fd45909f293d751cf926af00974b0ef86c1e Changes since revert: - Reverted a61aa4919ff7e9c14e8e47cdb447dd48913526dc for not fixing the jitless toggling issue on Chromium Win64 - Fix jitless toggling on Win64 by checking FLAG_jitless in EmbeddedDataWithMaybeRemappedEmbeddedBuiltins Original change's description: > Reland^3 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64"" > > This is a reland of 054ff044bc09696ab5dcc4fce4d0a406e6935ea9 > > Change since revert: > > - Remove assignment to FLAG_enable_short_builtins in test since > it's write-once in CFI. > > Original change's description: > > Reland^2 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" > > > > This is a reland of 1f504c36da9bab622072d65f80bbf819576c7d3f > > > > Changes since revert: > > > > - Removed disabling of RO heap sharing when --stress-snapshot is passed; > > was fixed by f4a6c628c9ac09fea8d367e41dc53f80564ffed5 > > - Fixed crashing tests that caused revert separately in > > a61aa4919ff7e9c14e8e47cdb447dd48913526dc > > > > Original change's description: > > > > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64 > > > > > > > > Reviewed-on: > > > https://chromium-review.googlesource.com/c/v8/v8/+/2873226 > > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#74422} > > > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855 > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > Reviewed-by: Adam Klein <adamk@chromium.org> > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > Reviewed-by: Dan Elphick <delphick@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#74448} > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460 > > Reviewed-by: Adam Klein <adamk@chromium.org> > > Commit-Queue: Shu-yu Guo <syg@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#74546} > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893567 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74548} TBR=ishell@chromium.org Bug: v8:11460 Change-Id: Ied925de5f886a906b1ca178365aee73155e679cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891697 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74560}
2021-05-13 22:31:02 +00:00
if (v8_enable_shared_ro_heap && v8_enable_pointer_compression &&
!v8_enable_pointer_compression_shared_cage) {
[heap] Share RO_SPACE pages with pointer compression This allows the configuration v8_enable_shared_ro_heap and v8_enable_pointer_compression on Linux and Android, although it still defaults to off. When pointer compression and read-only heap sharing are enabled, sharing is achieved by allocating ReadOnlyPages in shared memory that are retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are then remapped into the address space of the Isolate ultimately using mremap. To simplify the creation process the ReadOnlySpace memory for the first Isolate is created as before without any sharing. It is only when the ReadOnlySpace memory has been finalized that the shared memory is allocated and has its contents copied into it. The original memory is then released (with PC this means it's just released back to the BoundedPageAllocator) and immediately re-allocated as a shared mapping. Because we would like to make v8_enable_shared_ro_heap default to true at some point but can't make this conditional on the value returned by a method in the code we are yet to compile, the code required for sharing has been mostly changed to use ifs with ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where a compile error would result due to the absence of a class members without sharing. IsReadOnlySpaceShared() will evaluate CanAllocateSharedPages in the platform PageAllocator (with pointer compression and sharing enabled) once and cache that value so sharing cannot be toggled during the lifetime of the process. Bug: v8:10454 Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69174}
2020-07-31 12:52:57 +00:00
assert(
is_linux || is_chromeos || is_android,
"Sharing read-only heap with pointer compression is only supported on Linux or Android")
[heap] Share RO_SPACE pages with pointer compression This allows the configuration v8_enable_shared_ro_heap and v8_enable_pointer_compression on Linux and Android, although it still defaults to off. When pointer compression and read-only heap sharing are enabled, sharing is achieved by allocating ReadOnlyPages in shared memory that are retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are then remapped into the address space of the Isolate ultimately using mremap. To simplify the creation process the ReadOnlySpace memory for the first Isolate is created as before without any sharing. It is only when the ReadOnlySpace memory has been finalized that the shared memory is allocated and has its contents copied into it. The original memory is then released (with PC this means it's just released back to the BoundedPageAllocator) and immediately re-allocated as a shared mapping. Because we would like to make v8_enable_shared_ro_heap default to true at some point but can't make this conditional on the value returned by a method in the code we are yet to compile, the code required for sharing has been mostly changed to use ifs with ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where a compile error would result due to the absence of a class members without sharing. IsReadOnlySpaceShared() will evaluate CanAllocateSharedPages in the platform PageAllocator (with pointer compression and sharing enabled) once and cache that value so sharing cannot be toggled during the lifetime of the process. Bug: v8:10454 Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69174}
2020-07-31 12:52:57 +00:00
}
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
assert(!v8_enable_map_packing || !v8_enable_pointer_compression,
"Map packing does not support pointer compression")
assert(!v8_enable_map_packing || v8_current_cpu == "x64",
"Map packing is only supported on x64")
assert(!v8_enable_external_code_space || v8_enable_pointer_compression,
"External code space feature requires pointer compression")
assert(!v8_enable_pointer_compression_8gb || v8_enable_pointer_compression,
"Pointer compression for 8GB cages requires pointer compression")
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
assert(!v8_enable_sandbox || v8_enable_pointer_compression_shared_cage,
"The sandbox requires the shared pointer compression cage")
assert(!v8_enable_sandbox || v8_enable_external_code_space,
"The sandbox requires the external code space")
assert(!v8_expose_memory_corruption_api || v8_enable_sandbox,
"The Memory Corruption API requires the sandbox")
assert(
!v8_enable_pointer_compression_shared_cage || v8_enable_pointer_compression,
"Can't share a pointer compression cage if pointers aren't compressed")
assert(
!v8_enable_pointer_compression_shared_cage || v8_current_cpu == "x64" ||
v8_current_cpu == "arm64" || v8_current_cpu == "riscv64",
"Sharing a pointer compression cage is only supported on x64,arm64 and riscv64")
Reland^4 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" This is a reland of 8b74fd45909f293d751cf926af00974b0ef86c1e Changes since revert: - Reverted a61aa4919ff7e9c14e8e47cdb447dd48913526dc for not fixing the jitless toggling issue on Chromium Win64 - Fix jitless toggling on Win64 by checking FLAG_jitless in EmbeddedDataWithMaybeRemappedEmbeddedBuiltins Original change's description: > Reland^3 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64"" > > This is a reland of 054ff044bc09696ab5dcc4fce4d0a406e6935ea9 > > Change since revert: > > - Remove assignment to FLAG_enable_short_builtins in test since > it's write-once in CFI. > > Original change's description: > > Reland^2 "[ptr-cage] Turn on shared pointer cage by default for arm64 and x64" > > > > This is a reland of 1f504c36da9bab622072d65f80bbf819576c7d3f > > > > Changes since revert: > > > > - Removed disabling of RO heap sharing when --stress-snapshot is passed; > > was fixed by f4a6c628c9ac09fea8d367e41dc53f80564ffed5 > > - Fixed crashing tests that caused revert separately in > > a61aa4919ff7e9c14e8e47cdb447dd48913526dc > > > > Original change's description: > > > > [ptr-cage] Turn on shared pointer cage by default for arm64 and x64 > > > > > > > > Reviewed-on: > > > https://chromium-review.googlesource.com/c/v8/v8/+/2873226 > > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#74422} > > > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2878855 > > > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > > > Reviewed-by: Adam Klein <adamk@chromium.org> > > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > > Reviewed-by: Dan Elphick <delphick@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#74448} > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891460 > > Reviewed-by: Adam Klein <adamk@chromium.org> > > Commit-Queue: Shu-yu Guo <syg@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#74546} > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2893567 > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/master@{#74548} TBR=ishell@chromium.org Bug: v8:11460 Change-Id: Ied925de5f886a906b1ca178365aee73155e679cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2891697 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74560}
2021-05-13 22:31:02 +00:00
assert(!v8_enable_unconditional_write_barriers || !v8_disable_write_barriers,
"Write barriers can't be both enabled and disabled")
assert(!cppgc_enable_caged_heap || v8_current_cpu == "x64" ||
v8_current_cpu == "arm64" || v8_current_cpu == "loong64",
"CppGC caged heap requires 64bit platforms")
assert(!cppgc_enable_young_generation || cppgc_enable_caged_heap,
"Young generation in CppGC requires caged heap")
assert(!cppgc_enable_pointer_compression || cppgc_enable_caged_heap,
"Pointer compression in CppGC requires caged heap")
assert(
!v8_enable_conservative_stack_scanning ||
v8_enable_inner_pointer_resolution_osb ||
v8_enable_inner_pointer_resolution_mb,
"Conservative stack scanning requires inner pointer resolution (OSB or MB)")
if (v8_enable_single_generation == true) {
assert(
v8_enable_unconditional_write_barriers || v8_disable_write_barriers,
"Requires unconditional write barriers or none (which disables incremental marking)")
}
if (v8_fuchsia_use_vmex_resource) {
assert(target_os == "fuchsia", "VMEX resource only available on Fuchsia")
}
assert(!v8_enable_snapshot_compression || v8_use_zlib,
"Snapshot compression requires zlib")
v8_random_seed = "314159265"
v8_toolset_for_shell = "host"
###############################################################################
# Configurations
#
config("internal_config_base") {
# Only targets in this file and its subdirs can depend on this.
visibility = [ "./*" ]
configs = [ ":v8_tracing_config" ]
include_dirs = [
".",
"include",
"$target_gen_dir",
"$target_gen_dir/include",
]
}
config("internal_config") {
defines = []
# Only targets in this file and its subdirs can depend on this.
visibility = [ "./*" ]
configs = [
"//build/config/compiler:wexit_time_destructors",
":internal_config_base",
":v8_header_features",
":cppgc_header_features",
]
if (is_component_build) {
defines += [ "BUILDING_V8_SHARED" ]
}
if (v8_current_cpu == "riscv64" || v8_current_cpu == "riscv32") {
libs = [ "atomic" ]
}
}
# Should be applied to all targets that write trace events.
config("v8_tracing_config") {
if (v8_use_perfetto) {
include_dirs = [
"third_party/perfetto/include",
"$root_gen_dir/third_party/perfetto",
"$root_gen_dir/third_party/perfetto/build_config",
]
}
}
# This config should be applied to code using the libplatform.
config("libplatform_config") {
include_dirs = [ "include" ]
if (is_component_build) {
defines = [ "USING_V8_PLATFORM_SHARED" ]
}
}
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
# This config should be applied to code using the libbase.
config("libbase_config") {
if (is_component_build) {
defines = [ "USING_V8_BASE_SHARED" ]
}
libs = []
if (is_android && current_toolchain != host_toolchain) {
libs += [ "log" ]
}
include_dirs = [ "$target_gen_dir/include" ]
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
}
# Standalone cppgc cannot be built within chrome or with perfetto.
assert(!cppgc_is_standalone || !build_with_chromium)
assert(!cppgc_is_standalone || !v8_use_perfetto)
# This config should be applied to code using the cppgc_base.
config("cppgc_base_config") {
defines = []
if (cppgc_is_standalone) {
defines += [ "CPPGC_IS_STANDALONE" ]
}
}
# This config is only applied to v8_headers and is the basis for external_config
# but without setting the USING_V8_SHARED define, which means v8_headers can be
# used inside v8 itself.
config("headers_config") {
defines = []
configs = [
":v8_header_features",
":cppgc_header_features",
]
include_dirs = [
"include",
"$target_gen_dir/include",
]
}
# This config should only be applied to code using V8 and not any V8 code
# itself.
config("external_config") {
configs = [ ":headers_config" ]
defines = []
if (is_component_build) {
defines += [ "USING_V8_SHARED" ]
}
if (current_cpu == "riscv64" || current_cpu == "riscv32") {
libs = [ "atomic" ]
}
}
# This config should only be applied to code that needs to be explicitly
# aware of whether we are using startup data or not.
config("external_startup_data") {
if (v8_use_external_startup_data) {
defines = [ "V8_USE_EXTERNAL_STARTUP_DATA" ]
}
}
# List of defines that can appear in externally visible header files and that
# are controlled by args.gn.
external_v8_defines = [
"V8_ENABLE_CHECKS",
"V8_COMPRESS_POINTERS",
"V8_COMPRESS_POINTERS_IN_SHARED_CAGE",
Reland^2 "[ptr-cage] Rename IsolateRoot to PtrComprCageBase" This is a reland of e28dadc2070b202aab77b9e50a46e50be02f8f1c The original failure was due to a stale Win32 bot. The reland failure was due to idempotent task deduplication returning the exact same failure. See crbug/1196064 Original change's description: > [ptr-cage] Rename IsolateRoot to PtrComprCageBase > > Currently, IsolateRoot is both the address of the Isolate root and the > base address of the pointer compression reservation. This CL teases the > two uses apart by renaming IsolateRoot to PtrComprCageBase. > > - In addition to V8_COMPRESS_POINTERS, add a > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE (vs SHARED_CAGE). > > - Rename GetIsolate* helpers to GetPtrComprCageBase. When > V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE is true, the helpers remain as > aliases to GetPtrComprCageBase. > > - Rename kPtrComprIsolateRootAlignment to kPtrComprCageBaseAlignment. > > Bug: v8:11460 > Change-Id: I1d715f678ce9a0b5731895612ca14f56579b1c48 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2783672 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Auto-Submit: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73790} Bug: v8:11460 No-Try: true Tbr: ishell@chromium.org Tbr: rmcilroy@chromium.org Change-Id: Id69311cf3267ebe1297fff159de0be48b15b65a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2806546 Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#73795}
2021-04-05 19:42:59 +00:00
"V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE",
"V8_31BIT_SMIS_ON_64BIT_ARCH",
"V8_COMPRESS_ZONES",
"V8_ENABLE_SANDBOX",
"V8_DEPRECATION_WARNINGS",
"V8_IMMINENT_DEPRECATION_WARNINGS",
"V8_NO_ARGUMENTS_ADAPTOR",
"V8_USE_PERFETTO",
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
"V8_MAP_PACKING",
"V8_IS_TSAN",
]
enabled_external_v8_defines = []
if (v8_enable_v8_checks) {
enabled_external_v8_defines += [ "V8_ENABLE_CHECKS" ]
}
if (v8_enable_pointer_compression) {
enabled_external_v8_defines += [ "V8_COMPRESS_POINTERS" ]
if (v8_enable_pointer_compression_shared_cage) {
enabled_external_v8_defines += [ "V8_COMPRESS_POINTERS_IN_SHARED_CAGE" ]
} else {
enabled_external_v8_defines += [ "V8_COMPRESS_POINTERS_IN_ISOLATE_CAGE" ]
}
}
if (v8_enable_pointer_compression || v8_enable_31bit_smis_on_64bit_arch) {
enabled_external_v8_defines += [ "V8_31BIT_SMIS_ON_64BIT_ARCH" ]
}
if (v8_enable_zone_compression) {
enabled_external_v8_defines += [ "V8_COMPRESS_ZONES" ]
}
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
if (v8_enable_sandbox) {
enabled_external_v8_defines += [ "V8_ENABLE_SANDBOX" ]
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
}
if (v8_deprecation_warnings) {
enabled_external_v8_defines += [ "V8_DEPRECATION_WARNINGS" ]
}
if (v8_imminent_deprecation_warnings) {
enabled_external_v8_defines += [ "V8_IMMINENT_DEPRECATION_WARNINGS" ]
}
if (v8_use_perfetto) {
enabled_external_v8_defines += [ "V8_USE_PERFETTO" ]
}
Allowing map word to be used for other state in GC header. This CL adds features to pack/unpack map words. Currently V8 cannot store extra metadata in object headers -- because V8 objects do not have a proper header, but only a map pointer at the start of the object. To store per-object metadata like marking data, a side table is required as the per-object metadata storage. This CL enables V8 to use higher unused bits in a 64-bit map word as per-object metadata storage. Map pointer stores come with an extra step to encode the metadata into the pointer (we call it "map packing"). Map pointer loads will also remove the metadata bits as well (we call it "map packing"). Since the map word is no longer a valid pointer after packing, we also change the tag of the packed map word to make it looks like a Smi. This helps various GC and barrier code to correctly skip them instead of blindly dereferencing this invalid pointer. A ninja flag `v8_enable_map_packing` is provided to turn this map-packing feature on and off. It is disabled by default. * Only works on x64 platform, with `v8_enable_pointer_compression` set to `false` Bug: v8:11624 Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#73915}
2021-04-06 12:01:44 +00:00
if (v8_enable_map_packing) {
enabled_external_v8_defines += [ "V8_MAP_PACKING" ]
}
if (is_tsan) {
enabled_external_v8_defines += [ "V8_IS_TSAN" ]
}
disabled_external_v8_defines = external_v8_defines - enabled_external_v8_defines
# Put defines that are used in public headers here; public headers are
# defined in "v8_headers" and are included by embedders of V8.
config("v8_header_features") {
visibility = [ ":*" ]
if (v8_generate_external_defines_header) {
Revert "[build] Enable external flag header with defines" This reverts commit 1370b29e75e6a51e31f728e8f6f8f345badf67a2. Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409. Original change's description: > [build] Enable external flag header with defines > > Due to some unusual build failures on some trybots, > v8_generate_external_defines_header was reverted to false. This turns it > back on but changes the behaviour so that defines are added to the > command line as well as to the header. Because the generated header > checks that flags that should be unset are actually unset and flags that > should be set are either unset or set to 1, this will cause build > failures on many types of mismatches, although it will not detect where a > flag is not set on the command line when it is set by the header. > > If no further failures show up with this, the hybrid part can be removed > and the v8-gn.h header can stand on its own. > > Bug: v8:11292, v8:11341 > Change-Id: I1deeeebec58f79607e68a28f808649e884810923 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72327} TBR=mlippautz@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:11292 Bug: v8:11341 Change-Id: I6cf57014ef8be73c286ad9c5ebf597915f183717 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695400 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72748}
2021-02-15 13:26:12 +00:00
defines = [ "V8_GN_HEADER" ]
} else {
defines = enabled_external_v8_defines
}
}
# List of defines that can appear in externally visible cppgc header files and
# that are controlled by args.gn.
external_cppgc_defines = [
"CPPGC_SUPPORTS_OBJECT_NAMES",
"CPPGC_CAGED_HEAP",
"CPPGC_YOUNG_GENERATION",
"CPPGC_POINTER_COMPRESSION",
]
enabled_external_cppgc_defines = []
if (cppgc_enable_object_names) {
enabled_external_cppgc_defines += [ "CPPGC_SUPPORTS_OBJECT_NAMES" ]
}
if (cppgc_enable_caged_heap) {
enabled_external_cppgc_defines += [ "CPPGC_CAGED_HEAP" ]
# Always enable young generation compile time flag if caged heap is enabled.
cppgc_enable_young_generation = true
# Pointer compression regresses binary size on Fuchsia by about 300K.
# However, the change improves Oilpan memory by 15-20% (2-4% of PMF),
# which is beneficial for memory-impoverished platforms.
cppgc_enable_pointer_compression = true
}
if (cppgc_enable_young_generation) {
enabled_external_cppgc_defines += [ "CPPGC_YOUNG_GENERATION" ]
}
if (cppgc_enable_pointer_compression) {
enabled_external_cppgc_defines += [ "CPPGC_POINTER_COMPRESSION" ]
}
if (cppgc_enable_2gb_cage) {
enabled_external_cppgc_defines += [ "CPPGC_2GB_CAGE" ]
}
disabled_external_cppgc_defines =
external_cppgc_defines - enabled_external_cppgc_defines
config("cppgc_header_features") {
visibility = [ ":*" ]
if (v8_generate_external_defines_header) {
Revert "[build] Enable external flag header with defines" This reverts commit 1370b29e75e6a51e31f728e8f6f8f345badf67a2. Reason for revert: Breaks some targets that lack a dependency onto v8-gn.h, see https://crbug.com/1178409. Original change's description: > [build] Enable external flag header with defines > > Due to some unusual build failures on some trybots, > v8_generate_external_defines_header was reverted to false. This turns it > back on but changes the behaviour so that defines are added to the > command line as well as to the header. Because the generated header > checks that flags that should be unset are actually unset and flags that > should be set are either unset or set to 1, this will cause build > failures on many types of mismatches, although it will not detect where a > flag is not set on the command line when it is set by the header. > > If no further failures show up with this, the hybrid part can be removed > and the v8-gn.h header can stand on its own. > > Bug: v8:11292, v8:11341 > Change-Id: I1deeeebec58f79607e68a28f808649e884810923 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649041 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72327} TBR=mlippautz@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:11292 Bug: v8:11341 Change-Id: I6cf57014ef8be73c286ad9c5ebf597915f183717 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695400 Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72748}
2021-02-15 13:26:12 +00:00
defines = [ "V8_GN_HEADER" ]
} else {
defines = enabled_external_cppgc_defines
}
}
enabled_external_defines =
enabled_external_v8_defines + enabled_external_cppgc_defines
disabled_external_defines =
disabled_external_v8_defines + disabled_external_cppgc_defines
# Put defines here that are only used in our internal files and NEVER in
# external headers that embedders (such as chromium and node) might include.
config("features") {
# Only targets in this file and its subdirs can depend on this.
visibility = [ "./*" ]
defines = []
configs = [
":v8_header_features",
":cppgc_header_features",
]
if (cppgc_enable_verify_heap) {
defines += [ "CPPGC_VERIFY_HEAP" ]
}
if (cppgc_allow_allocations_in_prefinalizers) {
defines += [ "CPPGC_ALLOW_ALLOCATIONS_IN_PREFINALIZERS" ]
}
if (v8_embedder_string != "") {
defines += [ "V8_EMBEDDER_STRING=\"$v8_embedder_string\"" ]
}
if (v8_enable_disassembler) {
defines += [ "ENABLE_DISASSEMBLER" ]
}
if (v8_promise_internal_field_count != 0) {
defines +=
[ "V8_PROMISE_INTERNAL_FIELD_COUNT=${v8_promise_internal_field_count}" ]
}
defines +=
[ "V8_TYPED_ARRAY_MAX_SIZE_IN_HEAP=${v8_typed_array_max_size_in_heap}" ]
if (v8_enable_future) {
defines += [ "V8_ENABLE_FUTURE" ]
}
if (v8_enable_lite_mode) {
defines += [ "V8_LITE_MODE" ]
}
if (v8_enable_gdbjit) {
defines += [ "ENABLE_GDB_JIT_INTERFACE" ]
}
if (v8_enable_vtunejit) {
defines += [ "ENABLE_VTUNE_JIT_INTERFACE" ]
}
Reland "Support Intel VTune ITT API" This is a reland of 5f5b4b04078a5da96b4c8244241cf73dc928f721 Original change's description: > Support Intel VTune ITT API > > Add VTune domain support extension to use VTune Domain/Task API and > tagging trace data for particular JS code block. > > How to use: > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient > file to download intel/ittapi by 'gclient sync' > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true' > 3. Run d8 with flag '--enable-vtune-domain-support' > > The Vtune Domain/Task API can be invoked from JS to mark JS code block. > You can mark the start of a JS task by > vtunedomainmark(domain_name, task_name, "start") > and the end of a task by > vtunedomainmark(domain_name, task_name, "end") > Tasks can nest. > > The VTune API (ittapi) is integrated as an external third party library > while the v8_vtune_jit also relies on the VTune ittapi. We have another > patch almost ready which refactors the v8_vtune_jit related code to > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit > code after this patch stabilized and landed. > > > Contributed by fanchen.kong@intel.com > > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490 > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65409} Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65478}
2019-12-14 08:46:38 +00:00
if (v8_enable_vtunetracemark) {
defines += [ "ENABLE_VTUNE_TRACEMARK" ]
}
if (v8_enable_hugepage) {
defines += [ "ENABLE_HUGEPAGE" ]
}
if (v8_enable_object_print) {
defines += [ "OBJECT_PRINT" ]
}
if (v8_enable_verify_heap) {
defines += [ "VERIFY_HEAP" ]
}
if (v8_enable_verify_predictable) {
defines += [ "VERIFY_PREDICTABLE" ]
}
if (v8_enable_trace_maps) {
defines += [ "V8_TRACE_MAPS" ]
}
if (v8_enable_trace_unoptimized) {
defines += [ "V8_TRACE_UNOPTIMIZED" ]
}
if (v8_enable_trace_feedback_updates) {
defines += [ "V8_TRACE_FEEDBACK_UPDATES" ]
}
if (v8_enable_test_features) {
defines += [ "V8_ENABLE_ALLOCATION_TIMEOUT" ]
defines += [ "V8_ENABLE_FORCE_SLOW_PATH" ]
defines += [ "V8_ENABLE_DOUBLE_CONST_STORE_CHECK" ]
}
if (v8_enable_i18n_support) {
defines += [ "V8_INTL_SUPPORT" ]
}
if (v8_enable_handle_zapping) {
defines += [ "ENABLE_HANDLE_ZAPPING" ]
}
if (v8_code_comments == true) {
defines += [ "V8_CODE_COMMENTS" ]
}
if (v8_enable_debug_code) {
defines += [ "V8_ENABLE_DEBUG_CODE" ]
}
if (v8_enable_heap_snapshot_verify) {
defines += [ "V8_ENABLE_HEAP_SNAPSHOT_VERIFY" ]
}
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
if (v8_enable_snapshot_native_code_counters) {
defines += [ "V8_SNAPSHOT_NATIVE_CODE_COUNTERS" ]
}
if (v8_enable_single_generation) {
defines += [ "V8_ENABLE_SINGLE_GENERATION" ]
}
[heap] Add object start bitmap for conservative stack scanning With conservative stack scanning enabled, a snapshot of the call stack upon entry to GC will be used to determine part of the root-set. When the collector walks the stack, it looks at each value and determines whether it could be a potential on-heap object pointer. However, unlike with Handles, these on-stack pointers aren't guaranteed to point to the start of the object: the compiler may decide hide these pointers, and create interior pointers in C++ frames which the GC doesn't know about. The solution to this is to include an object start bitmap in the header of each page. Each bit in the bitmap represents a word in the page payload which is set when an object is allocated. This means that when the collector finds an arbitrary potential pointer into the page, it can walk backwards through the bitmap until it finds the relevant object's base pointer. To prevent the bitmap becoming stale after compaction, it is rebuilt during object sweeping. This is experimental, and currently only works with inline allocation disabled, and single generational collection. Bug: v8:10614 Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#69615}
2020-08-28 20:48:41 +00:00
if (v8_enable_conservative_stack_scanning) {
defines += [ "V8_ENABLE_CONSERVATIVE_STACK_SCANNING" ]
}
if (v8_enable_inner_pointer_resolution_osb) {
defines += [ "V8_ENABLE_INNER_POINTER_RESOLUTION_OSB" ]
}
if (v8_enable_inner_pointer_resolution_mb) {
defines += [ "V8_ENABLE_INNER_POINTER_RESOLUTION_MB" ]
}
if (v8_disable_write_barriers) {
defines += [ "V8_DISABLE_WRITE_BARRIERS" ]
}
if (v8_enable_third_party_heap) {
defines += [ "V8_ENABLE_THIRD_PARTY_HEAP" ]
}
if (v8_use_external_startup_data) {
defines += [ "V8_USE_EXTERNAL_STARTUP_DATA" ]
}
if (v8_enable_atomic_object_field_writes) {
defines += [ "V8_ATOMIC_OBJECT_FIELD_WRITES" ]
}
if (v8_enable_ignition_dispatch_counting) {
defines += [ "V8_IGNITION_DISPATCH_COUNTING" ]
}
if (v8_enable_lazy_source_positions) {
defines += [ "V8_ENABLE_LAZY_SOURCE_POSITIONS" ]
}
if (v8_use_siphash) {
defines += [ "V8_USE_SIPHASH" ]
}
if (v8_enable_shared_ro_heap) {
defines += [ "V8_SHARED_RO_HEAP" ]
}
Reland "V8 x64 backend doesn't emit ABI compliant stack frames" This is a reland of 3cda21de77d098a612eadf44d504b188a599c5f0 Original change's description: > V8 x64 backend doesn't emit ABI compliant stack frames > > On 64 bit Windows, the OS stack walking does not work because the V8 x64 > backend doesn't emit unwinding info and also because it doesn't emit ABI > compliant stack frames. See > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit > for more details. > > This problem can be fixed by observing that V8 frames usually all have the same > prolog and epilog: > > push rbp, > mov rbp, rsp > ... > pop rbp > ret N > > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows > should walk through V8 frames. Furthermore, since V8 Code objects are all > allocated in the same code-range for an Isolate, it is possible to register a > single PDATA/XDATA entry to cover stack walking for all the code generated > inside that code-range. > > This PR contains changes required to enable stack walking on Win64: > > EmbeddedFileWriter now adds assembler directives to the builtins > snapshot source file (embedded.cc) to emit additional entries in the .pdata and > in the .xdata section of the V8 executable. This takes care of stack walking > for embedded builtins. (The case of non-embedded builtins is not supported). > The x64 Assembler has been modified to collect the information required to emit > this unwind info for builtins. > > Stack walking for jitted code is handled is Isolate.cpp, by registering > dynamically PDATA/XDATA for the whole code-range address space every time a new > Isolate is initialized, and by unregistering them when the Isolate is > destroyed. > > Stack walking for WASM jitted code is handled is the same way in > wasm::NativeModule (wasm/wasm-code-manager.cpp). > > It is important to note that Crashpad and Breakpad are already registering > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded > builtins). Since it is not possible to register multiple PDATA entries for the > same address range, a new function is added to the V8 API: > SetUnhandledExceptionCallback() can be used by an embedder to register its own > unhandled exception handler for exceptions that arise in v8-generated code. > V8 embedders should be modified accordingly (code for this is in a separate PR > in the Chromium repository: > https://chromium-review.googlesource.com/c/chromium/src/+/1474703). > > All these changes are experimental, behind: > > the 'v8_win64_unwinding_info' build flag, and > the '--win64-unwinding-info' runtime flag. > > Bug: v8:3598 > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#60330} Bug: v8:3598 Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60581}
2019-04-01 21:43:23 +00:00
if (v8_win64_unwinding_info) {
defines += [ "V8_WIN64_UNWINDING_INFO" ]
}
if (v8_enable_regexp_interpreter_threaded_dispatch) {
defines += [ "V8_ENABLE_REGEXP_INTERPRETER_THREADED_DISPATCH" ]
}
if (v8_enable_snapshot_compression) {
defines += [ "V8_SNAPSHOT_COMPRESSION" ]
}
Reland "[arm64] Protect return addresses stored on stack" This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df 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/+/2051958 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#66254}
2020-02-12 11:45:31 +00:00
if (v8_control_flow_integrity) {
defines += [ "V8_ENABLE_CONTROL_FLOW_INTEGRITY" ]
}
if (v8_enable_cet_shadow_stack) {
defines += [ "V8_ENABLE_CET_SHADOW_STACK" ]
}
Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub This is the first piece of the wasm debugging prototype (besides the changes to add/remove breakpoints in WasmModuleObject made with https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737). This changelist adds the infrastructure for a GDB-remote stub that will be used to manage debugging sessions via the gdb-remote protocol. It enables the creation and termination of debugging sessions over TCP connections that are managed in a separate thread. The logic to actually send, receive and decode GDB-remote packets will be part of a future changelist. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Enables Wasm debugging with LLDB (default: false) --wasm-gdb-remote-port TCP port to be used for debugging (default: 8765) --wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting for a debugger (default: false) --trace-wasm-gdb-remote Enables tracing of Gdb-remote packets (default: false) Note that most of this code is "borrowed" from the code of the Chromium NaCL GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub). Implementation details: - class GdbServer acts as a singleton manager for the gdb-remote stub. It is instantiated as soon as the first Wasm module is loaded in the Wasm engine. - class GdbServerThread spawns the worker thread for the TCP connection. - class Transport manages the socket connection, in a portable way. - class Session represents a remote debugging session. - class Target represents a debugging target and it’s the place where the debugging packets will be processed and will implement the logic to debug a Wasm engine. Bug: chromium:1010467 Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66379}
2020-02-17 05:01:29 +00:00
if (v8_enable_wasm_gdb_remote_debugging) {
defines += [ "V8_ENABLE_WASM_GDB_REMOTE_DEBUGGING" ]
}
if (v8_enable_precise_zone_stats) {
defines += [ "V8_ENABLE_PRECISE_ZONE_STATS" ]
}
if (v8_fuzzilli) {
defines += [ "V8_FUZZILLI" ]
}
if (v8_enable_short_builtin_calls) {
defines += [ "V8_SHORT_BUILTIN_CALLS" ]
}
if (v8_enable_external_code_space) {
defines += [ "V8_EXTERNAL_CODE_SPACE" ]
}
if (v8_enable_maglev) {
defines += [ "V8_ENABLE_MAGLEV" ]
}
if (v8_enable_swiss_name_dictionary) {
defines += [ "V8_ENABLE_SWISS_NAME_DICTIONARY" ]
}
Step 1 (of 3-ish): Basic ETW Instrumentation in V8 Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
2021-01-05 18:43:34 +00:00
if (v8_enable_system_instrumentation) {
defines += [ "V8_ENABLE_SYSTEM_INSTRUMENTATION" ]
}
if (v8_enable_etw_stack_walking) {
defines += [ "V8_ENABLE_ETW_STACK_WALKING" ]
}
Step 1 (of 3-ish): Basic ETW Instrumentation in V8 Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
2021-01-05 18:43:34 +00:00
if (v8_etw_guid != "") {
defines += [ "V8_ETW_GUID=\"$v8_etw_guid\"" ]
}
if (v8_enable_webassembly) {
defines += [ "V8_ENABLE_WEBASSEMBLY" ]
}
if (v8_dict_property_const_tracking) {
defines += [ "V8_DICT_PROPERTY_CONST_TRACKING" ]
}
if (v8_enable_javascript_promise_hooks) {
defines += [ "V8_ENABLE_JAVASCRIPT_PROMISE_HOOKS" ]
}
if (v8_enable_allocation_folding) {
defines += [ "V8_ALLOCATION_FOLDING" ]
}
if (v8_allocation_site_tracking) {
defines += [ "V8_ALLOCATION_SITE_TRACKING" ]
}
if (v8_scriptormodule_legacy_lifetime) {
defines += [ "V8_SCRIPTORMODULE_LEGACY_LIFETIME" ]
}
if (v8_advanced_bigint_algorithms) {
defines += [ "V8_ADVANCED_BIGINT_ALGORITHMS" ]
}
if (v8_fuchsia_use_vmex_resource) {
defines += [ "V8_USE_VMEX_RESOURCE" ]
}
if (v8_expose_memory_corruption_api) {
defines += [ "V8_EXPOSE_MEMORY_CORRUPTION_API" ]
}
if (v8_enable_pointer_compression_8gb) {
defines += [ "V8_COMPRESS_POINTERS_8GB" ]
}
if (v8_enable_static_roots) {
defines += [ "V8_STATIC_ROOTS" ]
}
if (v8_use_zlib) {
defines += [ "V8_USE_ZLIB" ]
}
if (v8_use_libm_trig_functions) {
defines += [ "V8_USE_LIBM_TRIG_FUNCTIONS" ]
}
if (v8_value_deserializer_hard_fail) {
defines += [ "V8_VALUE_DESERIALIZER_HARD_FAIL" ]
}
}
config("toolchain") {
# Only targets in this file and its subdirs can depend on this.
visibility = [ "./*" ]
defines = []
cflags = []
ldflags = []
if (v8_current_cpu == "arm") {
defines += [ "V8_TARGET_ARCH_ARM" ]
if (arm_version >= 7) {
defines += [ "CAN_USE_ARMV7_INSTRUCTIONS" ]
}
if (arm_fpu == "vfpv3-d16") {
defines += [ "CAN_USE_VFP3_INSTRUCTIONS" ]
} else if (arm_fpu == "vfpv3") {
defines += [
"CAN_USE_VFP3_INSTRUCTIONS",
"CAN_USE_VFP32DREGS",
]
} else if (arm_fpu == "neon") {
defines += [
"CAN_USE_VFP3_INSTRUCTIONS",
"CAN_USE_VFP32DREGS",
"CAN_USE_NEON",
]
}
# TODO(infra): Add support for arm_test_noprobe.
if (current_cpu != "arm") {
# These defines ares used for the ARM simulator.
if (arm_float_abi == "hard") {
defines += [ "USE_EABI_HARDFLOAT=1" ]
} else if (arm_float_abi == "softfp") {
defines += [ "USE_EABI_HARDFLOAT=0" ]
}
}
}
if (v8_current_cpu == "arm64") {
defines += [ "V8_TARGET_ARCH_ARM64" ]
if (current_cpu == "arm64" && v8_control_flow_integrity && is_clang) {
# Mark assembly code as BTI-compatible.
asmflags = [ "-mmark-bti-property" ]
Reland "[arm64] Protect return addresses stored on stack" This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df 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/+/2051958 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#66254}
2020-02-12 11:45:31 +00:00
}
}
# Mips64el simulators.
if (target_is_simulator && v8_current_cpu == "mips64el") {
defines += [ "_MIPS_TARGET_SIMULATOR" ]
}
if (v8_current_cpu == "mips64el" || v8_current_cpu == "mips64") {
defines += [ "V8_TARGET_ARCH_MIPS64" ]
if (v8_can_use_fpu_instructions) {
defines += [ "CAN_USE_FPU_INSTRUCTIONS" ]
}
if (mips_use_msa) {
defines += [ "_MIPS_MSA" ]
}
if (host_byteorder == "little") {
defines += [ "V8_TARGET_ARCH_MIPS64_LE" ]
} else if (host_byteorder == "big") {
defines += [ "V8_TARGET_ARCH_MIPS64_BE" ]
}
if (v8_use_mips_abi_hardfloat) {
defines += [
"__mips_hard_float=1",
"CAN_USE_FPU_INSTRUCTIONS",
]
} else {
defines += [ "__mips_soft_float=1" ]
}
if (mips_arch_variant == "r6") {
defines += [ "_MIPS_ARCH_MIPS64R6" ]
} else if (mips_arch_variant == "r2") {
defines += [ "_MIPS_ARCH_MIPS64R2" ]
}
}
# loong64 simulators.
if (target_is_simulator && v8_current_cpu == "loong64") {
defines += [ "_LOONG64_TARGET_SIMULATOR" ]
}
if (v8_current_cpu == "loong64") {
defines += [ "V8_TARGET_ARCH_LOONG64" ]
}
if (v8_current_cpu == "s390" || v8_current_cpu == "s390x") {
defines += [ "V8_TARGET_ARCH_S390" ]
cflags += [ "-ffp-contract=off" ]
if (v8_current_cpu == "s390x") {
defines += [ "V8_TARGET_ARCH_S390X" ]
}
if (host_byteorder == "little") {
defines += [ "V8_TARGET_ARCH_S390_LE_SIM" ]
} else {
cflags += [ "-march=z196" ]
}
}
if (v8_current_cpu == "ppc" || v8_current_cpu == "ppc64") {
if (v8_current_cpu == "ppc") {
defines += [ "V8_TARGET_ARCH_PPC" ]
} else if (v8_current_cpu == "ppc64") {
defines += [ "V8_TARGET_ARCH_PPC64" ]
cflags += [ "-ffp-contract=off" ]
}
if (host_byteorder == "little") {
defines += [ "V8_TARGET_ARCH_PPC_LE" ]
} else if (host_byteorder == "big") {
defines += [ "V8_TARGET_ARCH_PPC_BE" ]
if (current_os == "aix") {
cflags += [
# Work around AIX ceil, trunc and round oddities.
"-mcpu=power5+",
"-mfprnd",
# Work around AIX assembler popcntb bug.
"-mno-popcntb",
]
}
}
}
# Under simulator build, compiler will not provide __riscv_xlen. Define here
if (v8_current_cpu == "riscv64") {
defines += [ "V8_TARGET_ARCH_RISCV64" ]
defines += [ "__riscv_xlen=64" ]
defines += [ "CAN_USE_FPU_INSTRUCTIONS" ]
if (!is_clang) {
cflags += [ "-ffp-contract=off" ]
}
if (target_is_simulator) {
defines += [ "CAN_USE_RVV_INSTRUCTIONS" ]
}
}
if (v8_current_cpu == "riscv32") {
defines += [ "V8_TARGET_ARCH_RISCV32" ]
defines += [ "__riscv_xlen=32" ]
defines += [ "CAN_USE_FPU_INSTRUCTIONS" ]
}
if (v8_current_cpu == "x86") {
defines += [ "V8_TARGET_ARCH_IA32" ]
if (is_win) {
# Ensure no surprising artifacts from 80bit double math with x86.
cflags += [ "/arch:SSE2" ]
}
}
if (v8_current_cpu == "x64") {
defines += [ "V8_TARGET_ARCH_X64" ]
if (is_win) {
# Increase the initial stack size. The default is 1MB, this is 2MB. This
# applies only to executables and shared libraries produced by V8 since
# ldflags are not pushed to dependants.
ldflags += [ "/STACK:2097152" ]
}
}
if (is_android && v8_android_log_stdout) {
defines += [ "V8_ANDROID_LOG_STDOUT" ]
}
# V8_TARGET_OS_ defines. The target OS may differ from host OS e.g. in
# mksnapshot. We additionally set V8_HAVE_TARGET_OS to determine that a
# target OS has in fact been set; otherwise we internally assume that target
# OS == host OS (see v8config.h).
if (target_os == "android") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_ANDROID" ]
} else if (target_os == "fuchsia") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_FUCHSIA" ]
} else if (target_os == "ios") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_IOS" ]
} else if (target_os == "linux") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_LINUX" ]
} else if (target_os == "mac") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_MACOS" ]
} else if (target_os == "win") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_WIN" ]
}
# TODO(infra): Support v8_enable_prof on Windows.
# TODO(infra): Add support for compiling with simulators.
if (v8_enable_debugging_features) {
if ((is_linux || is_chromeos) && v8_enable_backtrace) {
ldflags += [ "-rdynamic" ]
}
defines += [ "DEBUG" ]
if (v8_enable_slow_dchecks) {
defines += [ "ENABLE_SLOW_DCHECKS" ]
}
Revert "Reland "[build] Add V8-specific dcheck_always_on"" This reverts commit 67960ba110803b053a772eff7aeac6c5d2f23143. Reason for revert: This has been properly fixed by https://crrev.com/c/3053740. Now dcheck_always_on already defaults to false for subprojects like V8 and no other switch is required. The switch didn't fully work anyways due to https://crbug.com/1231890. Original change's description: > Reland "[build] Add V8-specific dcheck_always_on" > > This is a reland of cecc666f4d681dc6eca7c9a65ff9da05ea42f1e3 > > Depends on: > https://crrev.com/c/3043611 > > Original change's description: > > [build] Add V8-specific dcheck_always_on > > > > This makes the V8 dcheck control independent of Chromium's and > > prepares switching Chromium's default behavior without affecting V8 > > developers or builders. > > > > Preparation for: https://crrev.com/c/2893204 > > > > Bug: chromium:1225701 > > Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75827} > > Bug: chromium:1225701 > Change-Id: I56568b78592addba01793d2d14f768c9ee10103d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041670 > Reviewed-by: Liviu Rau <liviurau@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75839} Bug: chromium:1225701, chromium:1231890 Change-Id: I7e27f5774d8e162977f30f685da4b15dadcc1084 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055294 Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#75935}
2021-07-27 06:41:14 +00:00
} else if (dcheck_always_on) {
defines += [ "DEBUG" ]
}
if (v8_enable_verify_csa) {
defines += [ "ENABLE_VERIFY_CSA" ]
}
if (v8_enable_runtime_call_stats) {
defines += [ "V8_RUNTIME_CALL_STATS" ]
}
if (v8_no_inline) {
if (is_win) {
cflags += [ "/Ob0" ]
} else {
cflags += [
"-fno-inline-functions",
"-fno-inline",
]
}
}
if (is_clang) {
cflags += [
"-Wmissing-field-initializers",
"-Wunreachable-code",
# Google3 enables this warning, so we should also enable it to find issue
# earlier. See https://reviews.llvm.org/D56731 for details about this
# warning.
"-Wctad-maybe-unsupported",
# TODO(v8:12245): Fix shadowing instances and remove.
"-Wno-shadow",
]
if (v8_current_cpu == "x64" || v8_current_cpu == "arm64" ||
v8_current_cpu == "mips64el" || v8_current_cpu == "riscv64") {
cflags += [ "-Wshorten-64-to-32" ]
}
}
if (is_win) {
cflags += [
"/wd4245", # Conversion with signed/unsigned mismatch.
"/wd4267", # Conversion with possible loss of data.
"/wd4324", # Padding structure due to alignment.
"/wd4701", # Potentially uninitialized local variable.
"/wd4702", # Unreachable code.
"/wd4703", # Potentially uninitialized local pointer variable.
"/wd4709", # Comma operator within array index expr (bugged).
"/wd4714", # Function marked forceinline not inlined.
# MSVC assumes that control can get past an exhaustive switch and then
# warns if there's no return there (see https://crbug.com/v8/7658)
"/wd4715", # Not all control paths return a value.
"/wd4718", # Recursive call has no side-effect.
"/wd4723", # https://crbug.com/v8/7771
"/wd4724", # https://crbug.com/v8/7771
"/wd4800", # Forcing value to bool.
]
}
if (!is_clang && is_win) {
cflags += [
"/wd4506", # Benign "no definition for inline function"
# Warnings permanently disabled:
# C4091: 'typedef ': ignored on left of 'X' when no variable is
# declared.
# This happens in a number of Windows headers. Dumb.
"/wd4091",
# C4127: conditional expression is constant
# This warning can in theory catch dead code and other problems, but
# triggers in far too many desirable cases where the conditional
# expression is either set by macros or corresponds some legitimate
# compile-time constant expression (due to constant template args,
# conditionals comparing the sizes of different types, etc.). Some of
# these can be worked around, but it's not worth it.
"/wd4127",
# C4251: 'identifier' : class 'type' needs to have dll-interface to be
# used by clients of class 'type2'
# This is necessary for the shared library build.
"/wd4251",
# C4275: non dll-interface class used as base for dll-interface class
# This points out a potential (but rare) problem with referencing static
# fields of a non-exported base, through the base's non-exported inline
# functions, or directly. The warning is subtle enough that people just
# suppressed it when they saw it, so it's not worth it.
"/wd4275",
# C4312 is a VS 2015 64-bit warning for integer to larger pointer.
# TODO(brucedawson): fix warnings, crbug.com/554200
"/wd4312",
# C4324 warns when padding is added to fulfill alignas requirements,
# but can trigger in benign cases that are difficult to individually
# suppress.
"/wd4324",
# C4351: new behavior: elements of array 'array' will be default
# initialized
# This is a silly "warning" that basically just alerts you that the
# compiler is going to actually follow the language spec like it's
# supposed to, instead of not following it like old buggy versions did.
# There's absolutely no reason to turn this on.
"/wd4351",
# C4355: 'this': used in base member initializer list
# It's commonly useful to pass |this| to objects in a class' initializer
# list. While this warning can catch real bugs, most of the time the
# constructors in question don't attempt to call methods on the passed-in
# pointer (until later), and annotating every legit usage of this is
# simply more hassle than the warning is worth.
"/wd4355",
# C4503: 'identifier': decorated name length exceeded, name was
# truncated
# This only means that some long error messages might have truncated
# identifiers in the presence of lots of templates. It has no effect on
# program correctness and there's no real reason to waste time trying to
# prevent it.
"/wd4503",
# Warning C4589 says: "Constructor of abstract class ignores
# initializer for virtual base class." Disable this warning because it
# is flaky in VS 2015 RTM. It triggers on compiler generated
# copy-constructors in some cases.
"/wd4589",
# C4611: interaction between 'function' and C++ object destruction is
# non-portable
# This warning is unavoidable when using e.g. setjmp/longjmp. MSDN
# suggests using exceptions instead of setjmp/longjmp for C++, but
# Chromium code compiles without exception support. We therefore have to
# use setjmp/longjmp for e.g. JPEG decode error handling, which means we
# have to turn off this warning (and be careful about how object
# destruction happens in such cases).
"/wd4611",
# Warnings to evaluate and possibly fix/reenable later:
"/wd4100", # Unreferenced formal function parameter.
"/wd4121", # Alignment of a member was sensitive to packing.
"/wd4244", # Conversion: possible loss of data.
"/wd4505", # Unreferenced local function has been removed.
"/wd4510", # Default constructor could not be generated.
"/wd4512", # Assignment operator could not be generated.
"/wd4610", # Class can never be instantiated, constructor required.
"/wd4838", # Narrowing conversion. Doesn't seem to be very useful.
"/wd4995", # 'X': name was marked as #pragma deprecated
"/wd4996", # Deprecated function warning.
# These are variable shadowing warnings that are new in VS2015. We
# should work through these at some point -- they may be removed from
# the RTM release in the /W4 set.
"/wd4456",
"/wd4457",
"/wd4458",
"/wd4459",
# All of our compilers support the extensions below.
"/wd4200", # nonstandard extension used: zero-sized array in struct/union
"/wd4201", # nonstandard extension used: nameless struct/union
"/wd4204", # nonstandard extension used : non-constant aggregate
# initializer
"/wd4221", # nonstandard extension used : 'identifier' : cannot be
# initialized using address of automatic variable
# http://crbug.com/588506 - Conversion suppressions waiting on Clang
# -Wconversion.
"/wd4245", # 'conversion' : conversion from 'type1' to 'type2',
# signed/unsigned mismatch
"/wd4267", # 'var' : conversion from 'size_t' to 'type', possible loss of
# data
"/wd4305", # 'identifier' : truncation from 'type1' to 'type2'
"/wd4389", # 'operator' : signed/unsigned mismatch
"/wd4702", # unreachable code
# http://crbug.com/848979 - MSVC is more conservative than Clang with
# regards to variables initialized and consumed in different branches.
"/wd4701", # Potentially uninitialized local variable 'name' used
"/wd4703", # Potentially uninitialized local pointer variable 'name' used
# http://crbug.com/848979 - Remaining Clang permitted warnings.
"/wd4661", # 'identifier' : no suitable definition provided for explicit
# template instantiation request
"/wd4706", # assignment within conditional expression
# MSVC is stricter and requires a boolean expression.
"/wd4715", # 'function' : not all control paths return a value'
# MSVC does not analyze switch (enum) for completeness.
]
# TODO(https://crbug.com/1377771): Keep MSVC on C++17 until source code is
# made compatible with C++20.
cflags_cc = [ "/std:c++17" ]
}
if (!is_clang && !is_win) {
cflags += [
# Disable gcc warnings for optimizations based on the assumption that
# signed overflow does not occur. Generates false positives (see
# http://crbug.com/v8/6341).
"-Wno-strict-overflow",
# GCC assumes that control can get past an exhaustive switch and then
# warns if there's no return there (see https://crbug.com/v8/7658).
"-Wno-return-type",
# Disable gcc warnings for using enum constant in boolean context.
# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97266
"-Wno-int-in-bool-context",
# Disable gcc deprecation warnings, which are firing on implicit capture
# of `this` in capture-by-value lambdas and preventing a build roll which
# enables C++20 (see https://crbug.com/1374227).
"-Wno-deprecated",
]
}
# Chromium uses a hand-picked subset of UBSan coverage. We want everything.
if (is_ubsan) {
cflags += [ "-fsanitize=undefined" ]
}
}
# For code that is hot during mksnapshot. In fast-mksnapshot builds, we
# optimize some files even in debug builds to speed up mksnapshot times.
config("always_turbofanimize") {
configs = [ ":internal_config" ]
# TODO(crbug.com/621335) Rework this so that we don't have the confusion
# between "optimize_speed" and "optimize_max".
if (((is_posix && !is_android) || is_fuchsia) && !using_sanitizer) {
configs += [ "//build/config/compiler:optimize_speed" ]
} else {
configs += [ "//build/config/compiler:optimize_max" ]
}
}
# Configs for code coverage with gcov. Separate configs for cflags and ldflags
# to selectively influde cflags in non-test targets only.
config("v8_gcov_coverage_cflags") {
cflags = [
"-fprofile-arcs",
"-ftest-coverage",
# We already block on gcc warnings on other bots. Let's not block here to
# always generate coverage reports.
"-Wno-error",
]
}
config("v8_gcov_coverage_ldflags") {
ldflags = [ "-fprofile-arcs" ]
}
###############################################################################
# Actions
#
# Only for Windows clang builds. Converts the embedded.S file produced by
# mksnapshot into an embedded.cc file with corresponding inline assembly.
template("asm_to_inline_asm") {
name = target_name
if (name == "default") {
suffix = ""
} else {
suffix = "_$name"
}
action("asm_to_inline_asm_" + name) {
visibility = [ ":*" ] # Only targets in this file can depend on this.
assert(emit_builtins_as_inline_asm)
script = "tools/snapshot/asm_to_inline_asm.py"
deps = [ ":run_mksnapshot_" + name ]
sources = [ "$target_gen_dir/embedded${suffix}.S" ]
outputs = [ "$target_gen_dir/embedded${suffix}.cc" ]
args = invoker.args
args += [
rebase_path("$target_gen_dir/embedded${suffix}.S", root_build_dir),
rebase_path("$target_gen_dir/embedded${suffix}.cc", root_build_dir),
]
}
}
if (is_android && enable_java_templates) {
android_assets("v8_external_startup_data_assets") {
if (v8_use_external_startup_data) {
deps = [ "//v8" ]
renaming_sources = [ "$root_out_dir/snapshot_blob.bin" ]
if (current_cpu == "arm" || current_cpu == "x86") {
renaming_destinations = [ "snapshot_blob_32.bin" ]
} else {
renaming_destinations = [ "snapshot_blob_64.bin" ]
}
disable_compression = true
}
}
}
if (v8_postmortem_support) {
action("postmortem-metadata") {
# Only targets in this file and the top-level visibility target can
# depend on this.
visibility = [
":*",
"//:gn_visibility",
]
script = "tools/gen-postmortem-metadata.py"
# NOSORT
sources = [
"$target_gen_dir/torque-generated/instance-types.h",
"src/objects/allocation-site.h",
"src/objects/allocation-site-inl.h",
"src/objects/cell.h",
"src/objects/cell-inl.h",
"src/objects/code.h",
"src/objects/code-inl.h",
"src/objects/data-handler.h",
"src/objects/data-handler-inl.h",
"src/objects/descriptor-array.h",
"src/objects/descriptor-array-inl.h",
"src/objects/feedback-cell.h",
"src/objects/feedback-cell-inl.h",
"src/objects/fixed-array.h",
"src/objects/fixed-array-inl.h",
"src/objects/heap-number.h",
"src/objects/heap-number-inl.h",
"src/objects/heap-object.h",
"src/objects/heap-object-inl.h",
"src/objects/instance-type.h",
"src/objects/js-array-buffer.h",
"src/objects/js-array-buffer-inl.h",
"src/objects/js-array.h",
"src/objects/js-array-inl.h",
"src/objects/js-function-inl.h",
"src/objects/js-function.cc",
"src/objects/js-function.h",
"src/objects/js-objects.cc",
"src/objects/js-objects.h",
"src/objects/js-objects-inl.h",
"src/objects/js-promise.h",
"src/objects/js-promise-inl.h",
"src/objects/js-raw-json.cc",
"src/objects/js-raw-json.h",
"src/objects/js-raw-json-inl.h",
"src/objects/js-regexp.cc",
"src/objects/js-regexp.h",
"src/objects/js-regexp-inl.h",
"src/objects/js-regexp-string-iterator.h",
"src/objects/js-regexp-string-iterator-inl.h",
"src/objects/map.cc",
"src/objects/map.h",
"src/objects/map-inl.h",
"src/objects/megadom-handler.h",
"src/objects/megadom-handler-inl.h",
"src/objects/name.h",
"src/objects/name-inl.h",
"src/objects/objects.h",
"src/objects/objects-inl.h",
"src/objects/oddball.h",
"src/objects/oddball-inl.h",
"src/objects/primitive-heap-object.h",
"src/objects/primitive-heap-object-inl.h",
"src/objects/scope-info.h",
"src/objects/scope-info-inl.h",
"src/objects/script.h",
"src/objects/script-inl.h",
"src/objects/shared-function-info.cc",
"src/objects/shared-function-info.h",
"src/objects/shared-function-info-inl.h",
"src/objects/string.cc",
"src/objects/string-comparator.cc",
"src/objects/string-comparator.h",
"src/objects/string.h",
"src/objects/string-inl.h",
"src/objects/struct.h",
"src/objects/struct-inl.h",
]
outputs = [ "$target_gen_dir/debug-support.cc" ]
args = rebase_path(outputs, root_build_dir) +
rebase_path(sources, root_build_dir)
[torque] Generate instance types Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
2019-10-11 21:52:06 +00:00
deps = [ ":run_torque" ]
}
}
torque_files = [
"src/builtins/aggregate-error.tq",
"src/builtins/array-at.tq",
"src/builtins/array-concat.tq",
"src/builtins/array-copywithin.tq",
"src/builtins/array-every.tq",
"src/builtins/array-filter.tq",
"src/builtins/array-find.tq",
"src/builtins/array-findindex.tq",
"src/builtins/array-findlast.tq",
"src/builtins/array-findlastindex.tq",
"src/builtins/array-foreach.tq",
"src/builtins/array-from.tq",
"src/builtins/array-isarray.tq",
"src/builtins/array-join.tq",
"src/builtins/array-lastindexof.tq",
"src/builtins/array-map.tq",
"src/builtins/array-of.tq",
"src/builtins/array-reduce-right.tq",
"src/builtins/array-reduce.tq",
"src/builtins/array-reverse.tq",
"src/builtins/array-shift.tq",
"src/builtins/array-slice.tq",
"src/builtins/array-some.tq",
"src/builtins/array-splice.tq",
"src/builtins/array-to-reversed.tq",
"src/builtins/array-to-sorted.tq",
"src/builtins/array-to-spliced.tq",
"src/builtins/array-unshift.tq",
"src/builtins/array-with.tq",
"src/builtins/array.tq",
"src/builtins/arraybuffer.tq",
"src/builtins/base.tq",
"src/builtins/boolean.tq",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/builtins/builtins-bigint.tq",
"src/builtins/builtins-string.tq",
"src/builtins/cast.tq",
"src/builtins/collections.tq",
"src/builtins/constructor.tq",
"src/builtins/conversion.tq",
"src/builtins/convert.tq",
"src/builtins/console.tq",
"src/builtins/data-view.tq",
"src/builtins/finalization-registry.tq",
"src/builtins/frames.tq",
"src/builtins/frame-arguments.tq",
"src/builtins/function.tq",
"src/builtins/growable-fixed-array.tq",
"src/builtins/ic-callable.tq",
"src/builtins/ic.tq",
"src/builtins/internal-coverage.tq",
"src/builtins/internal.tq",
"src/builtins/iterator.tq",
"src/builtins/math.tq",
"src/builtins/number.tq",
"src/builtins/object-fromentries.tq",
"src/builtins/object.tq",
"src/builtins/promise-abstract-operations.tq",
"src/builtins/promise-all.tq",
"src/builtins/promise-all-element-closure.tq",
"src/builtins/promise-any.tq",
"src/builtins/promise-constructor.tq",
"src/builtins/promise-finally.tq",
"src/builtins/promise-misc.tq",
"src/builtins/promise-race.tq",
"src/builtins/promise-reaction-job.tq",
"src/builtins/promise-resolve.tq",
"src/builtins/promise-then.tq",
"src/builtins/promise-jobs.tq",
"src/builtins/proxy-constructor.tq",
"src/builtins/proxy-delete-property.tq",
"src/builtins/proxy-get-property.tq",
"src/builtins/proxy-get-prototype-of.tq",
"src/builtins/proxy-has-property.tq",
"src/builtins/proxy-is-extensible.tq",
"src/builtins/proxy-prevent-extensions.tq",
"src/builtins/proxy-revocable.tq",
"src/builtins/proxy-revoke.tq",
"src/builtins/proxy-set-property.tq",
"src/builtins/proxy-set-prototype-of.tq",
"src/builtins/proxy.tq",
"src/builtins/reflect.tq",
"src/builtins/regexp-exec.tq",
"src/builtins/regexp-match-all.tq",
"src/builtins/regexp-match.tq",
"src/builtins/regexp-replace.tq",
"src/builtins/regexp-search.tq",
"src/builtins/regexp-source.tq",
"src/builtins/regexp-split.tq",
"src/builtins/regexp-test.tq",
"src/builtins/regexp.tq",
"src/builtins/string-at.tq",
"src/builtins/string-endswith.tq",
"src/builtins/string-html.tq",
"src/builtins/string-includes.tq",
"src/builtins/string-indexof.tq",
"src/builtins/string-iterator.tq",
"src/builtins/string-match-search.tq",
"src/builtins/string-pad.tq",
"src/builtins/string-repeat.tq",
"src/builtins/string-replaceall.tq",
"src/builtins/string-slice.tq",
"src/builtins/string-startswith.tq",
"src/builtins/string-substr.tq",
"src/builtins/string-substring.tq",
"src/builtins/string-trim.tq",
"src/builtins/symbol.tq",
"src/builtins/torque-internal.tq",
"src/builtins/typed-array-at.tq",
"src/builtins/typed-array-createtypedarray.tq",
"src/builtins/typed-array-every.tq",
"src/builtins/typed-array-entries.tq",
"src/builtins/typed-array-filter.tq",
"src/builtins/typed-array-find.tq",
"src/builtins/typed-array-findindex.tq",
"src/builtins/typed-array-findlast.tq",
"src/builtins/typed-array-findlastindex.tq",
"src/builtins/typed-array-foreach.tq",
"src/builtins/typed-array-from.tq",
"src/builtins/typed-array-keys.tq",
"src/builtins/typed-array-of.tq",
"src/builtins/typed-array-reduce.tq",
"src/builtins/typed-array-reduceright.tq",
"src/builtins/typed-array-set.tq",
"src/builtins/typed-array-slice.tq",
"src/builtins/typed-array-some.tq",
"src/builtins/typed-array-sort.tq",
"src/builtins/typed-array-subarray.tq",
"src/builtins/typed-array-to-reversed.tq",
"src/builtins/typed-array-to-sorted.tq",
"src/builtins/typed-array-values.tq",
"src/builtins/typed-array-with.tq",
"src/builtins/typed-array.tq",
"src/builtins/weak-ref.tq",
"src/ic/handler-configuration.tq",
"src/objects/allocation-site.tq",
"src/objects/api-callbacks.tq",
"src/objects/arguments.tq",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/bigint.tq",
"src/objects/call-site-info.tq",
"src/objects/cell.tq",
"src/objects/code.tq",
"src/objects/contexts.tq",
"src/objects/data-handler.tq",
"src/objects/debug-objects.tq",
"src/objects/descriptor-array.tq",
"src/objects/embedder-data-array.tq",
"src/objects/feedback-cell.tq",
"src/objects/feedback-vector.tq",
"src/objects/fixed-array.tq",
"src/objects/foreign.tq",
"src/objects/free-space.tq",
"src/objects/heap-number.tq",
"src/objects/heap-object.tq",
"src/objects/js-array-buffer.tq",
"src/objects/js-array.tq",
"src/objects/js-atomics-synchronization.tq",
"src/objects/js-collection-iterator.tq",
"src/objects/js-collection.tq",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/js-function.tq",
"src/objects/js-generator.tq",
"src/objects/js-objects.tq",
"src/objects/js-promise.tq",
"src/objects/js-proxy.tq",
"src/objects/js-raw-json.tq",
"src/objects/js-regexp-string-iterator.tq",
"src/objects/js-regexp.tq",
"src/objects/js-shadow-realm.tq",
"src/objects/js-shared-array.tq",
Reland "[shared-struct] Prototype JS shared structs" This is a reland of 1025bf26e325bc1e746637a6e53ba8ab2e716ff1 Changes since revert: - TSAN issue fixed by https://crrev.com/c/3475084 - Skip the shared-struct-workers test until shared GC deadlock is fixed, being tracked in v8:12645 Original change's description: > [shared-struct] Prototype JS shared structs > > Unlike the Stage 1 proposal, for simplicity the prototype does not add > any new syntax, instead opting for exposing a SharedStructType > constructor which takes an array of field names. This type constructor > returns constructors for shared structs. > > Shared structs can be shared across Isolates, are fixed layout, have no > prototype, have no .constructor, and can only store primitives and > other shared structs. > > The initial prototype does not have TurboFan support. > > Bug: v8:12547 > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79156} Bug: v8:12547 Change-Id: Ic1f5cf9fa9791ae2d5d5dc7c110614ca10b5d98e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475078 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#79215}
2022-02-23 00:36:17 +00:00
"src/objects/js-struct.tq",
Reland "[Temporal] Part 1 - Skeleton" This is a reland of 0adc1410b1dae42b135b613ed86c18edafc83e3a 1. Fork out test/mjsunit/temporal/function-exist.js test to test/mjsunit/temporal/function-exist-no-i18n.js and mark function-exist FAIL in no_i18n build. Original change's description: > [Temporal] Part 1 - Skeleton > > 1. Expose all the functions to empty buildins. > 2. Wire up basic structure of classes and internal slots. > > Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/ > > This is just a CL to establish a skeleton for Temporal. > The Temporal is very big. The prototype CL is in > https://chromium-review.googlesource.com/c/v8/v8/+/2967755 > but too big to be reviewed so I break up the basic structure here first. > > Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel > Bug: v8:11544 > Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76819} Bug: v8:11544 Change-Id: I60eaface94ba9b3408cb235cd1ae425151a36732 Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324 Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77303}
2021-10-07 21:22:29 +00:00
"src/objects/js-temporal-objects.tq",
"src/objects/js-weak-refs.tq",
"src/objects/literal-objects.tq",
"src/objects/map.tq",
Reland "[ic] Add a new MegaDOM IC" This is a reland of c83c9590baf677665b0872ca68cba2c1cf3524c1 Changes since revert: nothing, issue was crbug.com/v8/11666 Original change's description: > [ic] Add a new MegaDOM IC > > This patch implements the MegaDOM IC setup and access. A new MegaDOM > IC state indicates that we've seen only DOM accessors at this access > site. > > This CL only adds support for DOM getters in LoadIC, other kinds of > access will be added in follow on CLs. > > Still remaining TODO before shipping: > 1. Have a mechanism to invalidate the protector > 2. Have a mechanism to find the accessors that aren't overloaded > 3. Use a new builtin to miss to runtime on access check failure > > Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2 > Bug: v8:11321 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239 > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Reviewed-by: Mythri Alle <mythria@chromium.org> > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73733} Bug: v8:11321 Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439 Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#74056}
2021-04-19 08:31:29 +00:00
"src/objects/megadom-handler.tq",
"src/objects/microtask.tq",
"src/objects/module.tq",
"src/objects/name.tq",
"src/objects/oddball.tq",
"src/objects/ordered-hash-table.tq",
"src/objects/primitive-heap-object.tq",
"src/objects/promise.tq",
"src/objects/property-array.tq",
"src/objects/property-cell.tq",
"src/objects/property-descriptor-object.tq",
"src/objects/prototype-info.tq",
"src/objects/regexp-match-info.tq",
"src/objects/scope-info.tq",
"src/objects/script.tq",
"src/objects/shared-function-info.tq",
"src/objects/source-text-module.tq",
"src/objects/string.tq",
"src/objects/struct.tq",
"src/objects/swiss-hash-table-helpers.tq",
"src/objects/swiss-name-dictionary.tq",
"src/objects/synthetic-module.tq",
"src/objects/template-objects.tq",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/templates.tq",
"src/objects/torque-defined-classes.tq",
Reland "[turbofan] extend type asserts to cover all JS types" This is a reland of 45227ffdb4319de48205a27cb5107342ac5a863e Differences: - Handle one more flags conflict in variants.py. - Disallow %VerifyType without --concurrent-recompilation. Original change's description: > [turbofan] extend type asserts to cover all JS types > > Extend type assertions to all types covering JavaScript values. > This is achieved by allocating type representations on the heap using > newly defined HeapObject subclasses. To allocate these in the compiler, > we disable concurrent compilation for the --assert-types flag for now. > > Fix two type errors that came up with the existing tests: > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of > OtherObject. > 2. OperationTyper::NumberToString(Type) can type the result as the > HeapConstant Factory::zero_string(). However, NumberToString does > not always produce this string. To avoid regressions, the CL keeps > the HeapConstant type and changes the runtime and builtin code to > always produce the canonical "0" string. > > A few tests were failing because they check for truncations to work > and prevent deoptimization. However, AssertType nodes destroy all > truncations (which is by design), so these tests are incompatible > and now disabled for the assert_types variant. > > Drive-by fix: a few minor Torque issues that came up. > > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77565} Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77596}
2021-10-27 20:38:52 +00:00
"src/objects/turbofan-types.tq",
"src/objects/turboshaft-types.tq",
"test/torque/test-torque.tq",
Reland ^2 "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" This is a reland of 9e48a24fd9b88712e4ec591c8b1fd40dc6381f18 Original change's description: > Reland "[array] Move Array.p.sort to Torque and use TimSort instead of QuickSort" > > The CL was reverted because it broke some tests in ChromeOS. > > > [array] Move Array.p.sort to Torque and use TimSort instead of QuickSort > > > > This CL changes the sorting algorithm used in Array.p.sort from > > QuickSort to TimSort (implemented in Torque). > > > > Detailed performance results can be found here: https://goo.gl/4E733J > > > > To save on code space, fast-paths are implemented as sets of > > function pointers instead of specializing generics. > > > > R=cbruni@chromium.org, jgruber@chromium.org > > > > Bug: v8:7382, v8:7624 > > Change-Id: I7cd4287e4562d84ab7c79c58ae30780630f976de > > Reviewed-on: https://chromium-review.googlesource.com/1151199 > > Commit-Queue: Simon Zünd <szuend@google.com> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#55003} > > Bug: v8:7382, v8:7624 > Change-Id: Ic7a3230f3708177774b0760f08b7659d83ec5505 > Reviewed-on: https://chromium-review.googlesource.com/1184901 > Commit-Queue: Simon Zünd <szuend@google.com> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55325} Bug: v8:7382, v8:7624 Change-Id: I297611f45c09967e0f6961156b0c9ebdebc7053f Reviewed-on: https://chromium-review.googlesource.com/1186801 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#55360}
2018-08-22 13:17:38 +00:00
"third_party/v8/builtins/array-sort.tq",
]
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
if (v8_enable_i18n_support) {
torque_files += [
"src/objects/intl-objects.tq",
"src/objects/js-break-iterator.tq",
"src/objects/js-collator.tq",
"src/objects/js-date-time-format.tq",
"src/objects/js-display-names.tq",
"src/objects/js-duration-format.tq",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/js-list-format.tq",
"src/objects/js-locale.tq",
"src/objects/js-number-format.tq",
"src/objects/js-plural-rules.tq",
"src/objects/js-relative-time-format.tq",
"src/objects/js-segment-iterator.tq",
"src/objects/js-segmenter.tq",
"src/objects/js-segments.tq",
]
}
if (v8_enable_webassembly) {
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
torque_files += [
"src/builtins/wasm.tq",
"src/debug/debug-wasm-objects.tq",
"src/wasm/wasm-objects.tq",
]
}
# Template for running torque
# When building with v8_verify_torque_generation_invariance=true we need
# to be able to run torque for both 32 and 64 bits in the same build
template("run_torque") {
if (target_name == "") {
suffix = ""
} else {
suffix = "_$target_name"
}
toolchain = invoker.toolchain
action("run_torque" + suffix) {
visibility = [
":*",
"test/cctest/:*",
"tools/debug_helper/:*",
"tools/gcmole/:*",
]
deps = [ ":torque($toolchain)" ]
script = "tools/run.py"
sources = torque_files
destination_folder = "$target_gen_dir/torque-generated$suffix"
outputs = [
"$destination_folder/bit-fields.h",
"$destination_folder/builtin-definitions.h",
"$destination_folder/class-debug-readers.cc",
"$destination_folder/class-debug-readers.h",
"$destination_folder/class-forward-declarations.h",
"$destination_folder/class-verifiers.cc",
"$destination_folder/class-verifiers.h",
"$destination_folder/csa-types.h",
"$destination_folder/debug-macros.cc",
"$destination_folder/debug-macros.h",
"$destination_folder/enum-verifiers.cc",
"$destination_folder/exported-macros-assembler.cc",
"$destination_folder/exported-macros-assembler.h",
"$destination_folder/factory.cc",
"$destination_folder/factory.inc",
"$destination_folder/instance-types.h",
"$destination_folder/interface-descriptors.inc",
"$destination_folder/objects-body-descriptors-inl.inc",
"$destination_folder/objects-printer.cc",
"$destination_folder/visitor-lists.h",
]
foreach(file, torque_files) {
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
filetq = string_replace(file, ".tq", "-tq")
outputs += [
"$destination_folder/$filetq-csa.cc",
"$destination_folder/$filetq-csa.h",
"$destination_folder/$filetq-inl.inc",
"$destination_folder/$filetq.cc",
"$destination_folder/$filetq.inc",
]
}
args = [
"./" + rebase_path(
get_label_info(":torque($toolchain)", "root_out_dir") + "/torque",
root_build_dir),
"-o",
rebase_path("$destination_folder", root_build_dir),
"-v8-root",
rebase_path(".", root_build_dir),
]
if (v8_annotate_torque_ir) {
args += [ "-annotate-ir" ]
}
if (defined(invoker.args)) {
args += invoker.args
}
args += torque_files
}
}
# Default run_torque action
run_torque("") {
toolchain = v8_generator_toolchain
}
if (v8_verify_torque_generation_invariance) {
run_torque("x86") {
toolchain = "//build/toolchain/linux:clang_x86"
}
run_torque("x64") {
args = [ "-m32" ]
toolchain = "//build/toolchain/linux:clang_x64"
}
action("compare_torque_runs") {
deps = [
":run_torque_x64",
":run_torque_x86",
]
report_file = "$target_gen_dir/torque_comparison_results.txt"
script = "tools/compare_torque_output.py"
args = [
rebase_path("$target_gen_dir/torque-generated_x64", root_build_dir),
rebase_path("$target_gen_dir/torque-generated_x86", root_build_dir),
rebase_path(report_file, root_build_dir),
]
outputs = [ report_file ]
}
}
group("v8_maybe_icu") {
if (v8_enable_i18n_support) {
public_deps = [ "//third_party/icu" ]
}
}
v8_header_set("torque_runtime_support") {
visibility = [ ":*" ]
sources = [ "src/torque/runtime-support.h" ]
configs = [ ":internal_config" ]
}
v8_source_set("torque_generated_initializers") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
deps = [
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
":generate_bytecode_builtins_list",
":run_torque",
":v8_base_without_compiler",
":v8_tracing",
]
public_deps = [
":torque_runtime_support",
":v8_maybe_icu",
]
sources = [
Reland "[torque] refactor: use -tq only in filenames derived from .tq files" This is a reland of 64caf2b0b26cb6c955fbbb81365ac54820de51a0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
2020-09-25 14:11:33 +00:00
"$target_gen_dir/torque-generated/csa-types.h",
"$target_gen_dir/torque-generated/enum-verifiers.cc",
"$target_gen_dir/torque-generated/exported-macros-assembler.cc",
"$target_gen_dir/torque-generated/exported-macros-assembler.h",
]
foreach(file, torque_files) {
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
filetq = string_replace(file, ".tq", "-tq")
sources += [
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"$target_gen_dir/torque-generated/$filetq-csa.cc",
"$target_gen_dir/torque-generated/$filetq-csa.h",
]
}
Revert "Reland^2 "[build] disable C++ optimization for mksnapshot code."" This reverts commit 6beea97e090423aec4f6e5eeb20d4ed84559a79b. Reason for revert: https://crbug.com/942497 Original change's description: > Reland^2 "[build] disable C++ optimization for mksnapshot code." > > This is a reland of a6b95a6acf23516d82fcfeba9e5d0e88dc64288a > > In addition to UBSan, also ASAN needs optimizations. > So this CL doesn't disable optimizations for all sanitizer builds. > > Original change's description: > > Reland "[build] disable C++ optimization for mksnapshot code." > > > > This is a reland of cee2f772c7e5c33967321b190cf568ff15497bc0 > > > > Original change's description: > > > [build] disable C++ optimization for mksnapshot code. > > > > > > By disabling C++ optimizations for code that's only run in mksnapshot, > > > that is, CSA and Torque-generated code, we can save compile time. > > > I observed up to 2x improvements of compile time for some files, > > > while the mksnapshot time did not increase significantly. > > > > > > Bug: v8:7629 > > > Change-Id: I96be2966611b2471b68023e0dd9e351d94f0013c > > > Reviewed-on: https://chromium-review.googlesource.com/c/1460941 > > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#59585} > > > > Bug: v8:7629 > > Change-Id: I8330f93173ab3d7b400e15ea4935bbe8256b250f > > Reviewed-on: https://chromium-review.googlesource.com/c/1473292 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#59606} > > Bug: v8:7629 > Change-Id: I42175c472d8e41345573df81645dfe3accc9d8c4 > Reviewed-on: https://chromium-review.googlesource.com/c/1475396 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59632} TBR=yangguo@chromium.org,sigurds@chromium.org,tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7629 chromium:942497 Change-Id: Ie51d7b53440230b41fb763541908cb1162d8850d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549158 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60577}
2019-04-02 14:35:58 +00:00
configs = [ ":internal_config" ]
}
v8_source_set("torque_generated_definitions") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
deps = [
":generate_bytecode_builtins_list",
":run_torque",
":v8_internal_headers",
":v8_libbase",
":v8_tracing",
]
Revert "Reland "[DEPS] Add abseil to deps"" This reverts commit 214ef26dd0bfd3a2794d8ec37f998c78bcfdaa27. Reason for revert: gcc bots are failing https://crbug.com/v8/12248 Original change's description: > Reland "[DEPS] Add abseil to deps" > > This is a reland of 3c49308ac6acbb7d41c01b0c3d8bd14604ea7b06 > > Original change's description: > > [DEPS] Add abseil to deps > > > > Add a dependency on the chromium abseil-cpp subdir mirror. > > > > Bug: v8:11006 > > Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70786} > > Bug: v8:11006 > Change-Id: I2befd2eadd11d485eee47c68119d93be9a3e1655 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504257 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76897} Bug: v8:11006 Change-Id: Icdc7ed108a49fa33a0233a1af8ba8e4d9daadfd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3191392 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77132}
2021-09-28 17:44:04 +00:00
public_deps = [ ":v8_maybe_icu" ]
sources = [
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"$target_gen_dir/torque-generated/class-forward-declarations.h",
Reland "[torque] refactor: use -tq only in filenames derived from .tq files" This is a reland of 64caf2b0b26cb6c955fbbb81365ac54820de51a0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
2020-09-25 14:11:33 +00:00
"$target_gen_dir/torque-generated/class-verifiers.cc",
"$target_gen_dir/torque-generated/class-verifiers.h",
"$target_gen_dir/torque-generated/factory.cc",
"$target_gen_dir/torque-generated/objects-printer.cc",
]
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
foreach(file, torque_files) {
filetq = string_replace(file, ".tq", "-tq")
sources += [
"$target_gen_dir/torque-generated/$filetq-inl.inc",
"$target_gen_dir/torque-generated/$filetq.cc",
"$target_gen_dir/torque-generated/$filetq.inc",
]
}
configs = [ ":internal_config" ]
}
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
action("generate_bytecode_builtins_list") {
script = "tools/run.py"
outputs = [ "$target_gen_dir/builtins-generated/bytecodes-builtins-list.h" ]
deps = [ ":bytecode_builtins_list_generator($v8_generator_toolchain)" ]
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
args = [
"./" + rebase_path(
get_label_info(
":bytecode_builtins_list_generator($v8_generator_toolchain)",
"root_out_dir") + "/bytecode_builtins_list_generator",
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
root_build_dir),
rebase_path("$target_gen_dir/builtins-generated/bytecodes-builtins-list.h",
root_build_dir),
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
]
}
# Template to generate different V8 snapshots based on different runtime flags.
# Can be invoked with run_mksnapshot(<name>). The target will resolve to
# run_mksnapshot_<name>. If <name> is "default", no file suffixes will be used.
# Otherwise files are suffixed, e.g. embedded_<name>.S and
# snapshot_blob_<name>.bin.
#
# The template exposes the variables:
# args: additional flags for mksnapshots
# embedded_suffix: a camel case suffix for method names in the embedded
# snapshot.
template("run_mksnapshot") {
name = target_name
if (name == "default") {
suffix = ""
} else {
suffix = "_$name"
}
action("run_mksnapshot_" + name) {
# Only targets in this file and running mkgrokdump can depend on this.
visibility = [
":*",
"tools/debug_helper:run_mkgrokdump",
]
deps = [ ":mksnapshot($v8_snapshot_toolchain)" ]
script = "tools/run.py"
sources = []
outputs = []
Reland "[builtins] Embed builtins into the binary" This is a reland of 491d5a81ddd5a6ced8cde8cdd40f85f3da786d6a Original change's description: > [builtins] Embed builtins into the binary > > This embeds code for off-heap-safe builtins into the binary. Actual > execution of embedded code is not implemented yet. > > The embedded file has the following format: > > namespace v8 { > namespace internal { > > namespace { > > V8_EMBEDDED_TEXT_HEADER(v8_embedded_blob_) > __asm__( /* builtin offsets and lengths */ ); > __asm__(V8_ASM_LABEL("Builtins_RecordWrite")); > __asm__( /* binary instruction stream */ ); > /* Repeat for other builtins. */ > > extern "C" const uint8_t v8_embedded_blob_[]; > static const uint32_t v8_embedded_blob_size_ = /* size in bytes */; > > } // namespace > > const uint8_t* DefaultEmbeddedBlob() { return v8_embedded_blob_; } > uint32_t DefaultEmbeddedBlobSize() { return v8_embedded_blob_size_; } > > } // namespace internal > } // namespace v8 > > Bug: v8:6666 > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux64_fyi_rel_ng > Change-Id: Ic989f01da69ebe2863f31d934bfbe2c5d6e80864 > Reviewed-on: https://chromium-review.googlesource.com/946011 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51759} TBR=yangguo@chromium.org Bug: v8:6666 Change-Id: I89b0498f22b4ce573723748d55d86a82ba285a88 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux64_fyi_rel_ng Reviewed-on: https://chromium-review.googlesource.com/957024 Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51832}
2018-03-09 09:29:10 +00:00
data = []
args = [
"./" + rebase_path(get_label_info(":mksnapshot($v8_snapshot_toolchain)",
"root_out_dir") + "/mksnapshot",
root_build_dir),
"--turbo_instruction_scheduling",
# In cross builds, the snapshot may be generated for both the host and
# target toolchains. The same host binary is used to generate both, so
# mksnapshot needs to know which target OS to use at runtime. It's weird,
# but the target OS is really |current_os|.
"--target_os=$current_os",
"--target_arch=$current_cpu",
"--embedded_src",
rebase_path("$target_gen_dir/embedded${suffix}.S", root_build_dir),
]
[diagnostics] Support --turbo-profiling for builtins Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
2020-05-21 15:51:40 +00:00
if (v8_enable_builtins_profiling) {
args += [ "--turbo-profiling" ]
}
if (v8_enable_builtins_profiling_verbose) {
args += [ "--turbo-profiling-verbose" ]
}
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
if (v8_builtins_profiling_log_file != "") {
sources += [ v8_builtins_profiling_log_file ]
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
args += [
"--turbo-profiling-input",
rebase_path(v8_builtins_profiling_log_file, root_build_dir),
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
]
# Replace this with --warn-about-builtin-profile-data to see the full
# list of builtins with incompatible profiles.
args += [ "--abort-on-bad-builtin-profile-data" ]
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
}
[diagnostics] Support --turbo-profiling for builtins Currently, if d8 is run with the --turbo-profiling flag, it prints info about every TurboFan-compiled function. This info includes the number of times that each basic block in the function was run. It also includes text representations of the function's schedule and code, so that the person reading the output can associate counters with blocks of code. The data about each function is currently stored in a BasicBlockProfiler::Data instance, which is attached to a list owned by the singleton BasicBlockProfiler. Each Data contains an std::vector<uint32_t> which represents how many times each block in the function has executed. The generated code for each block uses a raw pointer into the storage of that vector to implement incrementing the counter. With this change, if you compile with v8_enable_builtins_profiling and then run with --turbo-profiling, d8 will print that same info about builtins too. In order to generate code that can survive being serialized to a snapshot and reloaded, this change uses counters in the JS heap instead of a std::vector outside the JS heap. The steps for instrumentation are as follows: 1. Between scheduling and instruction selection, add code to increment the counter for each block. The counters array doesn't yet exist at this point, and allocation is disallowed, so at this point the code refers to a special marker value. 2. During finalization of the code, allocate a BasicBlockProfilingData object on the JS heap containing data equivalent to what is stored in BasicBlockProfiler::Data. This includes a ByteArray that is big enough to store the counters for each block. 3. Patch the reference in the BuiltinsConstantsTableBuilder so that instead of referring to the marker object, it now refers to this ByteArray. Also add the BasicBlockProfilingData object to a list that is attached to the heap roots so it can be easily accessed for printing. Because these steps include modifying the BuiltinsConstantsTableBuilder, this procedure is only applicable to builtins. Runtime-generated code still uses raw pointers into std::vector instances. In order to keep divergence between these code paths to a minimum, most work is done referring to instances of BasicBlockProfiler::Data (the C++ class), and functions are provided to copy back and forth between that type and BasicBlockProfilingData (the JS heap object). This change is intended only to make --turbo-profiling work consistently on more kinds of functions, but with some further work, this data could form the basis for: - code coverage info for fuzzers, and/or - hot-path info for profile-guided optimization. Bug: v8:10470, v8:9119 Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67944}
2020-05-21 15:51:40 +00:00
# This is needed to distinguish between generating code for the simulator
# and cross-compiling. The latter may need to run code on the host with the
# simulator but cannot use simulator-specific instructions.
if (target_is_simulator) {
args += [ "--target_is_simulator" ]
}
args += invoker.args
outputs += [ "$target_gen_dir/embedded${suffix}.S" ]
if (invoker.embedded_variant != "") {
Reland "[builtins] Embed builtins into the binary" This is a reland of 491d5a81ddd5a6ced8cde8cdd40f85f3da786d6a Original change's description: > [builtins] Embed builtins into the binary > > This embeds code for off-heap-safe builtins into the binary. Actual > execution of embedded code is not implemented yet. > > The embedded file has the following format: > > namespace v8 { > namespace internal { > > namespace { > > V8_EMBEDDED_TEXT_HEADER(v8_embedded_blob_) > __asm__( /* builtin offsets and lengths */ ); > __asm__(V8_ASM_LABEL("Builtins_RecordWrite")); > __asm__( /* binary instruction stream */ ); > /* Repeat for other builtins. */ > > extern "C" const uint8_t v8_embedded_blob_[]; > static const uint32_t v8_embedded_blob_size_ = /* size in bytes */; > > } // namespace > > const uint8_t* DefaultEmbeddedBlob() { return v8_embedded_blob_; } > uint32_t DefaultEmbeddedBlobSize() { return v8_embedded_blob_size_; } > > } // namespace internal > } // namespace v8 > > Bug: v8:6666 > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux64_fyi_rel_ng > Change-Id: Ic989f01da69ebe2863f31d934bfbe2c5d6e80864 > Reviewed-on: https://chromium-review.googlesource.com/946011 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51759} TBR=yangguo@chromium.org Bug: v8:6666 Change-Id: I89b0498f22b4ce573723748d55d86a82ba285a88 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux64_fyi_rel_ng Reviewed-on: https://chromium-review.googlesource.com/957024 Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51832}
2018-03-09 09:29:10 +00:00
args += [
"--embedded_variant",
invoker.embedded_variant,
Reland "[builtins] Embed builtins into the binary" This is a reland of 491d5a81ddd5a6ced8cde8cdd40f85f3da786d6a Original change's description: > [builtins] Embed builtins into the binary > > This embeds code for off-heap-safe builtins into the binary. Actual > execution of embedded code is not implemented yet. > > The embedded file has the following format: > > namespace v8 { > namespace internal { > > namespace { > > V8_EMBEDDED_TEXT_HEADER(v8_embedded_blob_) > __asm__( /* builtin offsets and lengths */ ); > __asm__(V8_ASM_LABEL("Builtins_RecordWrite")); > __asm__( /* binary instruction stream */ ); > /* Repeat for other builtins. */ > > extern "C" const uint8_t v8_embedded_blob_[]; > static const uint32_t v8_embedded_blob_size_ = /* size in bytes */; > > } // namespace > > const uint8_t* DefaultEmbeddedBlob() { return v8_embedded_blob_; } > uint32_t DefaultEmbeddedBlobSize() { return v8_embedded_blob_size_; } > > } // namespace internal > } // namespace v8 > > Bug: v8:6666 > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux64_fyi_rel_ng > Change-Id: Ic989f01da69ebe2863f31d934bfbe2c5d6e80864 > Reviewed-on: https://chromium-review.googlesource.com/946011 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#51759} TBR=yangguo@chromium.org Bug: v8:6666 Change-Id: I89b0498f22b4ce573723748d55d86a82ba285a88 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux64_fyi_rel_ng Reviewed-on: https://chromium-review.googlesource.com/957024 Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51832}
2018-03-09 09:29:10 +00:00
]
}
if (v8_random_seed != "0") {
args += [
"--random-seed",
v8_random_seed,
]
}
if (v8_os_page_size != "0") {
args += [
"--v8_os_page_size",
v8_os_page_size,
]
}
if (v8_use_external_startup_data) {
outputs += [ "$root_out_dir/snapshot_blob${suffix}.bin" ]
data += [ "$root_out_dir/snapshot_blob${suffix}.bin" ]
args += [
"--startup_blob",
rebase_path("$root_out_dir/snapshot_blob${suffix}.bin", root_build_dir),
]
} else {
outputs += [ "$target_gen_dir/snapshot${suffix}.cc" ]
args += [
"--startup_src",
rebase_path("$target_gen_dir/snapshot${suffix}.cc", root_build_dir),
]
}
if (v8_embed_script != "") {
sources += [ v8_embed_script ]
args += [ rebase_path(v8_embed_script, root_build_dir) ]
}
Reland "Reland "Reland "[code-comments] Put code comments into the code object""" This is a reland of 9c0a48580bc820d93a16f8914281a7359beb2a7a Original change's description: > Reland "Reland "[code-comments] Put code comments into the code object"" > > This is a reland of ed3d647284538e9d6f013ebf2c460697aa06a5df > > This reland fixes that padding at the end of Wasm instruction streams > triggered asserts in the code printer. > > Original change's description: > > Reland "[code-comments] Put code comments into the code object" > > > > This is a reland of e774cffe2bd3f00332209d4d5695221963888c96 > > > > This reland disables a test as v8:8548 is blocking it, which was > > broken by a recent CL. CQ did not catch this because the merge-base > > CQ used did not yet contain the CL that caused v8:8548. > > > > Original change's description: > > > [code-comments] Put code comments into the code object > > > > > > Code comments in the snapshot can now be enabled with gn > > > arg 'v8_enable_snapshot_code_comments' > > > > > > Bug: v8:7989 > > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3 > > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173 > > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#58020} > > > > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org > > > > Bug: v8:7989, v8:8548 > > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9 > > Reviewed-on: https://chromium-review.googlesource.com/c/1361166 > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#58028} > > Bug: v8:7989, v8:8548 > Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d > Reviewed-on: https://chromium-review.googlesource.com/c/1371784 > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58221} TBR=jgruber@chromium.org,mstarzinger@chromium.org Bug: v8:7989, v8:8548, v8:8593 Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b Reviewed-on: https://chromium-review.googlesource.com/c/1375919 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#58232}
2018-12-13 19:30:56 +00:00
if (v8_enable_snapshot_code_comments) {
args += [ "--code-comments" ]
}
if (v8_enable_snapshot_native_code_counters) {
args += [ "--native-code-counters" ]
} else {
# --native-code-counters is the default in debug mode so make sure we can
# unset it.
args += [ "--no-native-code-counters" ]
}
if (v8_enable_fast_mksnapshot) {
args += [ "--no-turbo-verify-allocation" ]
if (v8_current_cpu == "x86" || v8_current_cpu == "x64") {
args += [ "--no-turbo-rewrite-far-jumps" ]
}
if (v8_enable_debugging_features && v8_enable_slow_dchecks) {
# mksnapshot only accepts this flag if ENABLE_SLOW_DCHECKS is defined.
args += [ "--no-enable-slow-asserts" ]
}
}
if (v8_enable_verify_heap) {
args += [ "--verify-heap" ]
}
}
}
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
run_mksnapshot("default") {
args = []
embedded_variant = "Default"
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
}
if (emit_builtins_as_inline_asm) {
asm_to_inline_asm("default") {
args = []
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
}
}
action("v8_dump_build_config") {
script = "tools/testrunner/utils/dump_build_config.py"
outputs = [ "$root_out_dir/v8_build_config.json" ]
is_gcov_coverage = v8_code_coverage && !is_clang
is_full_debug = v8_enable_debugging_features && !v8_optimized_debug
args = [
rebase_path("$root_out_dir/v8_build_config.json", root_build_dir),
"current_cpu=\"$current_cpu\"",
Revert "Reland "[build] Add V8-specific dcheck_always_on"" This reverts commit 67960ba110803b053a772eff7aeac6c5d2f23143. Reason for revert: This has been properly fixed by https://crrev.com/c/3053740. Now dcheck_always_on already defaults to false for subprojects like V8 and no other switch is required. The switch didn't fully work anyways due to https://crbug.com/1231890. Original change's description: > Reland "[build] Add V8-specific dcheck_always_on" > > This is a reland of cecc666f4d681dc6eca7c9a65ff9da05ea42f1e3 > > Depends on: > https://crrev.com/c/3043611 > > Original change's description: > > [build] Add V8-specific dcheck_always_on > > > > This makes the V8 dcheck control independent of Chromium's and > > prepares switching Chromium's default behavior without affecting V8 > > developers or builders. > > > > Preparation for: https://crrev.com/c/2893204 > > > > Bug: chromium:1225701 > > Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#75827} > > Bug: chromium:1225701 > Change-Id: I56568b78592addba01793d2d14f768c9ee10103d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041670 > Reviewed-by: Liviu Rau <liviurau@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75839} Bug: chromium:1225701, chromium:1231890 Change-Id: I7e27f5774d8e162977f30f685da4b15dadcc1084 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055294 Reviewed-by: Liviu Rau <liviurau@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#75935}
2021-07-27 06:41:14 +00:00
"dcheck_always_on=$dcheck_always_on",
"is_android=$is_android",
"is_asan=$is_asan",
"is_cfi=$is_cfi",
"is_clang=$is_clang",
"is_component_build=$is_component_build",
"is_debug=$v8_enable_debugging_features",
"is_full_debug=$is_full_debug",
"is_gcov_coverage=$is_gcov_coverage",
"is_msan=$is_msan",
"is_tsan=$is_tsan",
"is_ubsan_vptr=$is_ubsan_vptr",
"target_cpu=\"$target_cpu\"",
"v8_current_cpu=\"$v8_current_cpu\"",
"v8_enable_atomic_object_field_writes=" +
"$v8_enable_atomic_object_field_writes",
"v8_enable_conservative_stack_scanning=" +
"$v8_enable_conservative_stack_scanning",
"v8_enable_concurrent_marking=$v8_enable_concurrent_marking",
"v8_enable_single_generation=$v8_enable_single_generation",
"v8_enable_i18n_support=$v8_enable_i18n_support",
"v8_enable_verify_predictable=$v8_enable_verify_predictable",
"v8_enable_verify_csa=$v8_enable_verify_csa",
"v8_enable_lite_mode=$v8_enable_lite_mode",
"v8_enable_runtime_call_stats=$v8_enable_runtime_call_stats",
"v8_enable_pointer_compression=$v8_enable_pointer_compression",
"v8_enable_pointer_compression_shared_cage=" +
"$v8_enable_pointer_compression_shared_cage",
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
"v8_enable_sandbox=$v8_enable_sandbox",
"v8_enable_shared_ro_heap=$v8_enable_shared_ro_heap",
"v8_disable_write_barriers=$v8_disable_write_barriers",
"v8_enable_third_party_heap=$v8_enable_third_party_heap",
"v8_enable_webassembly=$v8_enable_webassembly",
"v8_dict_property_const_tracking=$v8_dict_property_const_tracking",
"v8_control_flow_integrity=$v8_control_flow_integrity",
"v8_target_cpu=\"$v8_target_cpu\"",
"v8_enable_cet_shadow_stack=$v8_enable_cet_shadow_stack",
]
if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
args += [
"mips_arch_variant=\"$mips_arch_variant\"",
"mips_use_msa=$mips_use_msa",
]
}
}
###############################################################################
# Source Sets (aka static libraries)
#
v8_source_set("v8_snapshot") {
visibility = [ ":*" ] # Targets in this file can depend on this.
deps = [
":v8_internal_headers",
":v8_libbase",
]
public_deps = [
# This should be public so downstream targets can declare the snapshot
# output file as their inputs.
":run_mksnapshot_default",
]
# Do not publicize any header to remove build dependency.
public = []
sources = [ "src/init/setup-isolate-deserialize.cc" ]
if (v8_control_flow_integrity) {
sources += [ "src/deoptimizer/deoptimizer-cfi-builtins.cc" ]
}
if (emit_builtins_as_inline_asm) {
deps += [ ":asm_to_inline_asm_default" ]
sources += [ "$target_gen_dir/embedded.cc" ]
} else {
sources += [ "$target_gen_dir/embedded.S" ]
}
configs = [ ":internal_config" ]
if (v8_use_external_startup_data) {
deps += [ ":v8_base" ]
sources += [ "src/snapshot/snapshot-external.cc" ]
} else {
# Also top-level visibility targets can depend on this.
visibility += [ "//:gn_visibility" ]
Revert "Reland "[DEPS] Add abseil to deps"" This reverts commit 214ef26dd0bfd3a2794d8ec37f998c78bcfdaa27. Reason for revert: gcc bots are failing https://crbug.com/v8/12248 Original change's description: > Reland "[DEPS] Add abseil to deps" > > This is a reland of 3c49308ac6acbb7d41c01b0c3d8bd14604ea7b06 > > Original change's description: > > [DEPS] Add abseil to deps > > > > Add a dependency on the chromium abseil-cpp subdir mirror. > > > > Bug: v8:11006 > > Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70786} > > Bug: v8:11006 > Change-Id: I2befd2eadd11d485eee47c68119d93be9a3e1655 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504257 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76897} Bug: v8:11006 Change-Id: Icdc7ed108a49fa33a0233a1af8ba8e4d9daadfd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3191392 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77132}
2021-09-28 17:44:04 +00:00
public_deps += [ ":v8_maybe_icu" ]
sources += [ "$target_gen_dir/snapshot.cc" ]
}
}
v8_source_set("v8_initializers") {
visibility = [
":*",
"test/cctest:*",
]
allow_circular_includes_from = [ ":torque_generated_initializers" ]
deps = [
":torque_generated_initializers",
":v8_base_without_compiler",
":v8_shared_internal_headers",
":v8_tracing",
]
sources = [
### gcmole(all) ###
"src/builtins/builtins-array-gen.cc",
"src/builtins/builtins-array-gen.h",
"src/builtins/builtins-async-function-gen.cc",
"src/builtins/builtins-async-gen.cc",
"src/builtins/builtins-async-gen.h",
[async-iteration] implement AsyncGenerator - Introduce new struct AsyncGeneratorRequest, which holds information pertinent to resuming execution of an AsyncGenerator, such as the Promise associated with the async generator request. It is intended to be used as a singly linked list, and holds a pointer to the next item in te queue. - Introduce JSAsyncGeneratorObject (subclass of JSGeneratorObject), which includes several new internal fields (`queue` which contains a singly linked list of AsyncGeneratorRequest objects, and `await_input` which contains the sent value from an Await expression (This is necessary to prevent function.sent (used by yield*) from having the sent value observably overwritten during execution). - Modify SuspendGenerator to accept a set of Flags, which indicate whether the suspend is for a Yield or Await, and whether it takes place on an async generator or ES6 generator. - Introduce interpreter intrinsics and TF intrinsic lowering for accessing the await input of an async generator - Modify the JSGeneratorStore operator to understand whether or not it's suspending for a normal yield, or an AsyncGenerator Await. This ensures appropriate registers are stored. - Add versions of ResumeGeneratorTrampoline which store the input value in a different field depending on wether it's an AsyncGenerator Await resume, or an ordinary resume. Also modifies whether debug code will assert that the generator object is a JSGeneratorObject or a JSAsyncGeneratorObject depending on the resume type. BUG=v8:5855 R=bmeurer@chromium.org, rmcilroy@chromium.org, jgruber@chromium.org, littledan@chromium.org, neis@chromium.org TBR=marja@chromium.org Change-Id: I9d58df1d344465fc937fe7eed322424204497187 Reviewed-on: https://chromium-review.googlesource.com/446961 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#44240}
2017-03-29 13:41:45 +00:00
"src/builtins/builtins-async-generator-gen.cc",
"src/builtins/builtins-async-iterator-gen.cc",
"src/builtins/builtins-bigint-gen.cc",
"src/builtins/builtins-bigint-gen.h",
"src/builtins/builtins-call-gen.cc",
"src/builtins/builtins-call-gen.h",
"src/builtins/builtins-collections-gen.cc",
"src/builtins/builtins-collections-gen.h",
"src/builtins/builtins-constructor-gen.cc",
"src/builtins/builtins-constructor-gen.h",
"src/builtins/builtins-constructor.h",
"src/builtins/builtins-conversion-gen.cc",
"src/builtins/builtins-data-view-gen.h",
"src/builtins/builtins-date-gen.cc",
"src/builtins/builtins-generator-gen.cc",
"src/builtins/builtins-global-gen.cc",
"src/builtins/builtins-handler-gen.cc",
"src/builtins/builtins-ic-gen.cc",
"src/builtins/builtins-internal-gen.cc",
"src/builtins/builtins-interpreter-gen.cc",
"src/builtins/builtins-intl-gen.cc",
"src/builtins/builtins-iterator-gen.cc",
"src/builtins/builtins-iterator-gen.h",
"src/builtins/builtins-lazy-gen.cc",
"src/builtins/builtins-lazy-gen.h",
"src/builtins/builtins-microtask-queue-gen.cc",
"src/builtins/builtins-number-gen.cc",
"src/builtins/builtins-object-gen.cc",
"src/builtins/builtins-object-gen.h",
"src/builtins/builtins-promise-gen.cc",
"src/builtins/builtins-promise-gen.h",
"src/builtins/builtins-proxy-gen.cc",
"src/builtins/builtins-proxy-gen.h",
"src/builtins/builtins-regexp-gen.cc",
"src/builtins/builtins-regexp-gen.h",
"src/builtins/builtins-shadow-realm-gen.cc",
"src/builtins/builtins-sharedarraybuffer-gen.cc",
"src/builtins/builtins-string-gen.cc",
"src/builtins/builtins-string-gen.h",
"src/builtins/builtins-temporal-gen.cc",
"src/builtins/builtins-typed-array-gen.cc",
"src/builtins/builtins-typed-array-gen.h",
"src/builtins/builtins-utils-gen.h",
"src/builtins/growable-fixed-array-gen.cc",
"src/builtins/growable-fixed-array-gen.h",
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
"src/builtins/profile-data-reader.cc",
"src/builtins/profile-data-reader.h",
"src/builtins/setup-builtins-internal.cc",
"src/builtins/torque-csa-header-includes.h",
"src/codegen/code-stub-assembler.cc",
"src/codegen/code-stub-assembler.h",
"src/heap/setup-heap-internal.cc",
"src/ic/accessor-assembler.cc",
"src/ic/accessor-assembler.h",
"src/ic/binary-op-assembler.cc",
"src/ic/binary-op-assembler.h",
"src/ic/keyed-store-generic.cc",
"src/ic/keyed-store-generic.h",
"src/ic/unary-op-assembler.cc",
"src/ic/unary-op-assembler.h",
"src/interpreter/interpreter-assembler.cc",
"src/interpreter/interpreter-assembler.h",
"src/interpreter/interpreter-generator.cc",
"src/interpreter/interpreter-generator.h",
"src/interpreter/interpreter-intrinsics-generator.cc",
"src/interpreter/interpreter-intrinsics-generator.h",
"src/numbers/integer-literal-inl.h",
"src/numbers/integer-literal.h",
]
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
if (v8_enable_webassembly) {
sources += [
"src/builtins/builtins-wasm-gen.cc",
"src/builtins/builtins-wasm-gen.h",
]
}
if (v8_current_cpu == "x86") {
sources += [
### gcmole(ia32) ###
"src/builtins/ia32/builtins-ia32.cc",
]
} else if (v8_current_cpu == "x64") {
sources += [
### gcmole(x64) ###
"src/builtins/x64/builtins-x64.cc",
]
} else if (v8_current_cpu == "arm") {
sources += [
### gcmole(arm) ###
"src/builtins/arm/builtins-arm.cc",
]
} else if (v8_current_cpu == "arm64") {
sources += [
### gcmole(arm64) ###
"src/builtins/arm64/builtins-arm64.cc",
]
} else if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
sources += [
### gcmole(mips64el) ###
"src/builtins/mips64/builtins-mips64.cc",
]
} else if (v8_current_cpu == "loong64") {
sources += [
### gcmole(loong64) ###
"src/builtins/loong64/builtins-loong64.cc",
]
} else if (v8_current_cpu == "ppc") {
sources += [
### gcmole(ppc) ###
"src/builtins/ppc/builtins-ppc.cc",
]
} else if (v8_current_cpu == "ppc64") {
sources += [
### gcmole(ppc64) ###
"src/builtins/ppc/builtins-ppc.cc",
]
} else if (v8_current_cpu == "s390" || v8_current_cpu == "s390x") {
sources += [
### gcmole(s390) ###
"src/builtins/s390/builtins-s390.cc",
]
} else if (v8_current_cpu == "riscv64") {
sources += [
### gcmole(riscv64) ###
"src/builtins/riscv/builtins-riscv.cc",
]
} else if (v8_current_cpu == "riscv32") {
sources += [
### gcmole(riscv32) ###
"src/builtins/riscv/builtins-riscv.cc",
]
}
if (!v8_enable_i18n_support) {
sources -= [ "src/builtins/builtins-intl-gen.cc" ]
}
Revert "Reland^2 "[build] disable C++ optimization for mksnapshot code."" This reverts commit 6beea97e090423aec4f6e5eeb20d4ed84559a79b. Reason for revert: https://crbug.com/942497 Original change's description: > Reland^2 "[build] disable C++ optimization for mksnapshot code." > > This is a reland of a6b95a6acf23516d82fcfeba9e5d0e88dc64288a > > In addition to UBSan, also ASAN needs optimizations. > So this CL doesn't disable optimizations for all sanitizer builds. > > Original change's description: > > Reland "[build] disable C++ optimization for mksnapshot code." > > > > This is a reland of cee2f772c7e5c33967321b190cf568ff15497bc0 > > > > Original change's description: > > > [build] disable C++ optimization for mksnapshot code. > > > > > > By disabling C++ optimizations for code that's only run in mksnapshot, > > > that is, CSA and Torque-generated code, we can save compile time. > > > I observed up to 2x improvements of compile time for some files, > > > while the mksnapshot time did not increase significantly. > > > > > > Bug: v8:7629 > > > Change-Id: I96be2966611b2471b68023e0dd9e351d94f0013c > > > Reviewed-on: https://chromium-review.googlesource.com/c/1460941 > > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#59585} > > > > Bug: v8:7629 > > Change-Id: I8330f93173ab3d7b400e15ea4935bbe8256b250f > > Reviewed-on: https://chromium-review.googlesource.com/c/1473292 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org> > > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#59606} > > Bug: v8:7629 > Change-Id: I42175c472d8e41345573df81645dfe3accc9d8c4 > Reviewed-on: https://chromium-review.googlesource.com/c/1475396 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#59632} TBR=yangguo@chromium.org,sigurds@chromium.org,tebbi@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7629 chromium:942497 Change-Id: Ie51d7b53440230b41fb763541908cb1162d8850d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549158 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60577}
2019-04-02 14:35:58 +00:00
configs = [ ":internal_config" ]
}
v8_source_set("v8_init") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
deps = [
":v8_base_without_compiler",
":v8_initializers",
":v8_tracing",
]
sources = [
### gcmole(all) ###
"src/init/setup-isolate-full.cc",
]
Revert "Reland "[DEPS] Add abseil to deps"" This reverts commit 214ef26dd0bfd3a2794d8ec37f998c78bcfdaa27. Reason for revert: gcc bots are failing https://crbug.com/v8/12248 Original change's description: > Reland "[DEPS] Add abseil to deps" > > This is a reland of 3c49308ac6acbb7d41c01b0c3d8bd14604ea7b06 > > Original change's description: > > [DEPS] Add abseil to deps > > > > Add a dependency on the chromium abseil-cpp subdir mirror. > > > > Bug: v8:11006 > > Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70786} > > Bug: v8:11006 > Change-Id: I2befd2eadd11d485eee47c68119d93be9a3e1655 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504257 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76897} Bug: v8:11006 Change-Id: Icdc7ed108a49fa33a0233a1af8ba8e4d9daadfd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3191392 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77132}
2021-09-28 17:44:04 +00:00
public_deps = [ ":v8_maybe_icu" ]
configs = [ ":internal_config" ]
}
# This is split out to be a non-code containing target that the Chromium browser
# DLL can depend upon to get only a version string.
v8_header_set("v8_version") {
configs = [ ":internal_config" ]
sources = [
"include/v8-value-serializer-version.h",
"include/v8-version-string.h",
"include/v8-version.h",
]
}
v8_header_set("v8_config_headers") {
configs = [ ":internal_config" ]
sources = [
"include/v8-platform.h",
"include/v8config.h",
]
deps = []
if (v8_generate_external_defines_header) {
sources += [ "$target_gen_dir/include/v8-gn.h" ]
deps += [ ":gen_v8_gn" ]
}
}
# This is split out to be a non-code containing target that the Chromium browser
# can depend upon to get basic v8 types.
v8_header_set("v8_headers") {
configs = [ ":internal_config" ]
public_configs = [ ":headers_config" ]
sources = [
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-array-buffer.h",
"include/v8-callbacks.h",
"include/v8-container.h",
"include/v8-context.h",
"include/v8-cppgc.h",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-data.h",
"include/v8-date.h",
"include/v8-debug.h",
"include/v8-embedder-heap.h",
Reland "[profiler] Surface VM & Embedder State" This is a reland of 2d087f237eadd78f5545548675642f013fdfe675 The changes are : * Fix redundant reinterpret_cast in test file for MSVC failure https://crbug.com/v8/12476 * Fix flaky test https://crbug.com/v8/12475 If a sample is captured during a GC, no embedder context is obtained defaulting to EMPTY. This is the expected behavior, made it in clear in implementation and in test. * Synchronized the embedder context filter behavior with existing native context filter. Original change's description: > Add APIs to surface VMState and new EmbedderState to CpuProfile samples. > > EmbedderState: > * An EmbedderState is defined as a value uint8_t and a v8::context used > for filtering. > * EmbedderStates are stack allocated by the embedder, construction and > destruction set/unset the state to the isolate thread local top. > * A v8::context is used to filter states that are added to a CpuProfile, > if the CpuProfile do not have a ContextFilter set or if contexts do not > match, state defaults to Empty. > > * v8:StateTag is already propagated all the way to a Sample, simply add > an API to surface it. > > VMState: > Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e > Bug: chromium:1263871 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072 > Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78250} Bug: chromium:1263871 Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037 Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78281}
2021-12-07 07:28:08 +00:00
"include/v8-embedder-state-scope.h",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-exception.h",
"include/v8-extension.h",
"include/v8-external.h",
"include/v8-fast-api-calls.h",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-forward.h",
"include/v8-function-callback.h",
"include/v8-function.h",
"include/v8-initialization.h",
"include/v8-internal.h",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-isolate.h",
"include/v8-json.h",
"include/v8-local-handle.h",
"include/v8-locker.h",
"include/v8-maybe.h",
"include/v8-memory-span.h",
"include/v8-message.h",
"include/v8-microtask-queue.h",
"include/v8-microtask.h",
"include/v8-object.h",
"include/v8-persistent-handle.h",
"include/v8-primitive-object.h",
"include/v8-primitive.h",
"include/v8-profiler.h",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-promise.h",
"include/v8-proxy.h",
"include/v8-regexp.h",
"include/v8-script.h",
"include/v8-snapshot.h",
"include/v8-statistics.h",
"include/v8-template.h",
"include/v8-traced-handle.h",
"include/v8-typed-array.h",
"include/v8-unwinder.h",
"include/v8-util.h",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
"include/v8-value-serializer.h",
"include/v8-value.h",
"include/v8-wasm.h",
"include/v8-weak-callback-info.h",
"include/v8.h",
]
sources += [
# The following headers cannot be platform-specific. The include validation
# of `gn gen $dir --check` requires all header files to be available on all
# platforms.
"include/v8-wasm-trap-handler-posix.h",
"include/v8-wasm-trap-handler-win.h",
]
public_deps = [ ":v8_config_headers" ]
deps = [
":cppgc_headers",
":v8_version",
]
}
if (v8_generate_external_defines_header) {
action("gen_v8_gn") {
visibility = [ ":*" ]
script = "tools/gen-v8-gn.py"
outputs = [ "$target_gen_dir/include/v8-gn.h" ]
args = [
"-o",
rebase_path("$target_gen_dir/include/v8-gn.h", root_build_dir),
]
foreach(define, enabled_external_defines) {
args += [
"-p",
define,
]
}
foreach(define, disabled_external_defines) {
args += [
"-n",
define,
]
}
}
}
# This is split out to share basic headers with Torque and everything else:(
v8_header_set("v8_shared_internal_headers") {
visibility = [
":*",
"test/*",
"tools/*",
]
configs = [ ":internal_config" ]
sources = [
"src/common/globals.h",
"src/wasm/wasm-constants.h",
"src/wasm/wasm-limits.h",
]
deps = [
":v8_headers",
":v8_libbase",
]
}
v8_header_set("v8_flags") {
visibility = [
":*",
"tools/*",
]
configs = [ ":internal_config" ]
sources = [
"src/flags/flag-definitions.h",
"src/flags/flags.h",
]
deps = [
":v8_libbase",
":v8_shared_internal_headers",
]
}
v8_header_set("v8_internal_headers") {
configs = [ ":internal_config" ]
sources = [
### gcmole(all) ###
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
"$target_gen_dir/builtins-generated/bytecodes-builtins-list.h",
"//base/trace_event/common/trace_event_common.h",
"include/cppgc/common.h",
Revert "[build] Separate out inspector as a shared library" This reverts commit 92bfb63cace73b967644abb6a26e8703350a7507. Reason for revert: Broke build https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/43249/overview Original change's description: > [build] Separate out inspector as a shared library > > This makes src/inspector:inspector into a v8_component producing a > shared library in component builds. To enable this, all of its exported > are now marked with V8_INSPECTOR_EXPORT. > > This also inverts the dependency between src/inspector:inspector and > :v8_base_without_compiler, and instead makes d8 and some tests depend on > inspector rather than getting it via v8. > > As a result, the no_check_targets exclusions list in .gn is reduced. > > Ultimately embedders like chromium should depend on :v8 and optionally > src/inspector:inspector, but to allow that transition to occur, this > renames :v8 to :v8_lib and introduces a new :v8 which depends on v8 and > inspector. Once all embedders have changed to reflect the new structure, > this part can be reverted. > > Bug: v8:11917 > Change-Id: Ia8b15f07fb15acc5e1f111b1a80248def4285fd0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999088 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75532} Bug: v8:11917 Change-Id: I0ed27ed95211d13b8b3438a8c0a42d577806c475 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003452 Auto-Submit: Zhi An Ng <zhin@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75533}
2021-07-02 16:14:44 +00:00
"include/v8-inspector-protocol.h",
"include/v8-inspector.h",
"include/v8-metrics.h",
"include/v8-unwinder-state.h",
"include/v8-wasm-trap-handler-posix.h",
"src/api/api-arguments-inl.h",
"src/api/api-arguments.h",
"src/api/api-inl.h",
"src/api/api-macros-undef.h",
"src/api/api-macros.h",
"src/api/api-natives.h",
"src/api/api.h",
"src/ast/ast-function-literal-id-reindexer.h",
"src/ast/ast-source-ranges.h",
"src/ast/ast-traversal-visitor.h",
"src/ast/ast-value-factory.h",
"src/ast/ast.h",
"src/ast/modules.h",
"src/ast/prettyprinter.h",
"src/ast/scopes.h",
"src/ast/source-range-ast-visitor.h",
"src/ast/variables.h",
"src/baseline/baseline-assembler-inl.h",
"src/baseline/baseline-assembler.h",
"src/baseline/baseline-batch-compiler.h",
"src/baseline/baseline-compiler.h",
"src/baseline/baseline.h",
Reland "[sparkplug] Change bytecode offset mapping and introduce iterator." This is a reland of a8b61ef521c51e0d1d84ed744e893273ed5d516c The main reason for the revert was not related to this CL and was fixed with https://crrev.com/c/2739646 In addition debug output in d8.test.verifySourcePositions was removed due to TSAN complaints. Original change's description: > [sparkplug] Change bytecode offset mapping and introduce iterator. > > Previously, we recorded pairs of (bytecode offset, sparkplug pc) to > create a mapping of bytecode offset <-> sparkplug pc. > These pairs were only recorded after builtin/runtime calls. > In preparation for deoptimizing to Sparkplug, we need a more precise > mapping. > With this CL, we record positions for every bytecode. Instead of storing > a pair of (bytecode offset, sparkplug pc), we store only the pc, > calculating the bytecode offset from the index in the mapping table. > For easier use an iterator to access the mapping is introduced. > > Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of flaky failures. > > Bug: v8:11420, v8:11429 > Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189 > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73186} > > Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6 Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745335 Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#73293}
2021-03-09 11:18:52 +00:00
"src/baseline/bytecode-offset-iterator.h",
"src/builtins/accessors.h",
"src/builtins/builtins-constructor.h",
"src/builtins/builtins-definitions.h",
"src/builtins/builtins-descriptors.h",
"src/builtins/builtins-promise.h",
"src/builtins/builtins-utils-inl.h",
"src/builtins/builtins-utils.h",
"src/builtins/builtins.h",
"src/builtins/constants-table-builder.h",
Profile-guided optimization of builtins Design doc: https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing V8 can already collect data about how many times each basic block in the builtins is run. This change enables using that data for profile-guided optimization. New comments in BUILD.gn describe how to use this feature. A few implementation details worth mentioning, which aren't covered in the design doc: - BasicBlockProfilerData currently contains an array of RPO numbers. However, this array is always just [0, 1, 2, 3, ...], so this change removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument ensures that the removal is valid. - RPO numbers, while useful for printing data that matches with the stringified schedule, are not useful for matching profiling data with blocks that haven't been scheduled yet. This change adds a new array of block IDs in BasicBlockProfilerData, so that block counters can be used for PGO. - Basic block counters need to be written to a file so that they can be provided to a subsequent run of mksnapshot, but the design doc doesn't specify the transfer format or what file is used. In this change, I propose using the existing v8.log file for that purpose. Block count records look like this: block,TestLessThanHandler,37,29405 This line indicates that block ID 37 in TestLessThanHandler was run 29405 times. If multiple lines refer to the same block, the reader adds them all together. I like this format because it's easy to use: - V8 already has robust logic for creating the log file, naming it to avoid conflicts in multi-process situations, etc. - Line order doesn't matter, and interleaved writes from various logging sources are fine, given that V8 writes each line atomically. - Combining multiple sources of profiling data is as simple as concatenating their v8.log files together. - It is a good idea to avoid making any changes based on profiling data if the function being compiled doesn't match the one that was profiled, since it is common to use profiling data downloaded from a central lab which is updated only periodically. To check whether a function matches, I propose using a hash of the Graph state right before scheduling. This might be stricter than necessary, as some changes to the function might be small enough that the profile data is still relevant, but I'd rather err on the side of not making incorrect changes. This hash is also written to the v8.log file, in a line that looks like this: builtin_hash,LdaZeroHandler,3387822046 Bug: v8:10470 Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#69008}
2020-07-16 16:37:08 +00:00
"src/builtins/profile-data-reader.h",
Reland "Reland "Reland "[compiler][wasm] Align Frame slots to value size""" This is a reland of 352b9ecbdb090cbb22ee3362fadae28f86ba6773 The test/fix CL has been merged in, as the fixes to return slot accounting are needed to fix Arm64 issues turned up by the fuzzers: https://chromium-review.googlesource.com/c/v8/v8/+/2644139 The reverted fix for Wasm return slot allocation is added in patchset #2, to avoid fuzzer issues that it fixed: https://chromium-review.googlesource.com/c/v8/v8/+/2683024 TBR=neis@chromium.org Original change's description: > Reland "Reland "[compiler][wasm] Align Frame slots to value size"" > > This is a reland of 1694925c728a1be1b7084028bd656ddfc75f6471 > > Minor fix to linkage for constexpr. > > TBR=ahaas@chromium.org,neis@chromium.org > > Original change's description: > > Reland "[compiler][wasm] Align Frame slots to value size" > > > > This is a reland of cddaf66c371c2433c391434776f31b8771c5ab45 > > > > Original change's description: > > > [compiler][wasm] Align Frame slots to value size > > > > > > - Adds an AlignedSlotAllocator class and tests, to unify slot > > > allocation. This attempts to use alignment holes for smaller > > > values. > > > - Reworks Frame to use the new allocator for stack slots. > > > - Reworks LinkageAllocator to use the new allocator for stack > > > slots and for ARMv7 FP register aliasing. > > > - Fixes the RegisterAllocator to align spill slots. > > > - Fixes InstructionSelector to align spill slots. > > > > > > Bug: v8:9198 > > > > > > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840 > > > Commit-Queue: Bill Budge <bbudge@chromium.org> > > > Reviewed-by: Georg Neis <neis@chromium.org> > > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#71644} > > > > Bug: v8:9198 > > Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390 > > Commit-Queue: Bill Budge <bbudge@chromium.org> > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#72195} > > Bug: v8:9198 > Change-Id: I91e02b823af8ec925dacf075388fb22e3eeb3384 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640890 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Commit-Queue: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72209} Bug: v8:9198 Change-Id: Ia5cf63af4e5991bc7cf42da9972ffd044fc829f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733177 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#73238}
2021-03-03 23:20:31 +00:00
"src/codegen/aligned-slot-allocator.h",
"src/codegen/assembler-arch.h",
"src/codegen/assembler-inl.h",
"src/codegen/assembler.h",
"src/codegen/atomic-memory-order.h",
Reland "Background merging of deserialized scripts" This is a reland of commit e895b7af73728b0f1431549dbd52db37e8b1b577 The unit test has been updated to work correctly when --stress-incremental-marking is enabled. Original change's description: > Background merging of deserialized scripts > > Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions > with which an embedder could request that V8 merge newly deserialized > script data into an existing Script from the Isolate's compilation > cache. This change implements those new functions. This functionality is > still disabled by default due to the flag > merge_background_deserialized_script_with_compilation_cache. > > The goal of this new functionality is to reduce memory usage when > multiple frames load the same script with a long delay between (long > enough for the script to have been evicted from Blink's in-memory cache > and for the top-level SharedFunctionInfo to be flushed). In that case, > there are two Script objects for the same script: one which was found in > the Isolate compilation cache (the "old" script), and one which was > recently deserialized (the "new" script). The new script's object graph > is essentially standalone: it may point to internalized strings and > readonly objects such as the empty feedback metadata, but otherwise > it is unconnected to the rest of the heap. The merging logic takes any > useful data from the new script's object graph and attaches it into the > old script's object graph, so that the new Script object and any other > duplicated objects can be discarded. More specifically: > > 1. If the new Script has a SharedFunctionInfo for a particular function > literal, and the old Script does not, then the old Script is updated > to refer to the new SharedFunctionInfo. > 2. If the new Script has a compiled SharedFunctionInfo for a particular > function literal, and the old Script has an uncompiled > SharedFunctionInfo, then the old SharedFunctionInfo is updated to > point to the function_data and feedback_metadata from the new > SharedFunctionInfo. > 3. If any used object from the new object graph points to a > SharedFunctionInfo, where the old object graph contains a matching > SharedFunctionInfo for the same function literal, then that pointer > is updated to point to the old SharedFunctionInfo. > > The document at [0] includes diagrams showing an example merge on a very > small script. > > Steps 1 and 2 above are pretty simple, but step 3 requires walking a > possibly large set of objects, so this new API lets the embedder run > step 3 from a background thread. Steps 1 and 2 are performed later, on > the main thread. > > The next important question is: in what ways can the old script's object > graph be modified during the background execution of step 3, or during > the time after step 3 but before steps 1 and 2? > > A. SharedFunctionInfos can go from compiled to uncompiled due to > flushing. This is okay; the worst outcome is that the function would > need to be compiled again later. Such a risk is already present, > since V8 doesn't keep IsCompiledScopes for every compiled function in > a background-deserialized script. > B. SharedFunctionInfos can go from uncompiled to compiled due to lazy > compilation. This is also okay; the merge completion logic on the > main thread will just keep this lazily compiled data rather than > inserting compiled data from the newly deserialized object graph. > C. SharedFunctionInfos can be cleared from the Script's weak array if > they are no longer referenced. This is mostly okay, because any > SharedFunctionInfo that is needed by the background merge is strongly > referenced and therefore can't be cleared. The only problem arises if > the top-level SharedFunctionInfo gets cleared, so the merge task must > deliberately keep a reference to that one. > D. SharedFunctionInfos can be created if they are needed due to lazy > compilation of a parent function. This change is somewhat troublesome > because it invalidates the background thread's work and requires a > re-traversal on the main thread to update any pointers that should > point to this lazily compiled SharedFunctionInfo. > > At a high level, this change implements three previously unimplemented > functions in BackgroundDeserializeTask (in compiler.cc) and updates one: > > - BackgroundDeserializeTask::SourceTextAvailable, run on the main > thread, checks whether there is a matching Script in the Isolate > compilation cache which doesn't already have a top-level > SharedFunctionInfo. If so, it saves that Script in a persistent > handle. > - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks > whether the persistent handle from the first step exists (a fast > operation which can be called from any thread). > - BackgroundDeserializeTask::MergeWithExistingScript, run on a > background thread, performs step 3 of the merge described above and > generates lists of persistent data describing how the main thread can > complete the merge. > - BackgroundDeserializeTask::Finish is updated to perform the merge > steps 1 and 2 listed above, as well as a possible re-traversal of the > graph if required due to newly created SharedFunctionInfos in the old > Script. > > The merge logic has nothing to do with deserialization, and indeed I > hope to reuse it for background compilation tasks as well, so it is all > contained within a new class BackgroundMergeTask (in compiler.h,cc). It > uses a second class, ForwardPointersVisitor (in compiler.cc) to perform > the object visitation that updates pointers to SharedFunctionInfos. > > [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit > > Bug: v8:12808 > Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#81941} Bug: v8:12808 Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#82045}
2022-07-28 15:56:42 +00:00
"src/codegen/background-merge-task.h",
"src/codegen/bailout-reason.h",
"src/codegen/callable.h",
"src/codegen/code-comments.h",
"src/codegen/code-desc.h",
"src/codegen/code-factory.h",
"src/codegen/code-reference.h",
"src/codegen/compilation-cache.h",
"src/codegen/compiler.h",
"src/codegen/constant-pool.h",
"src/codegen/constants-arch.h",
"src/codegen/cpu-features.h",
"src/codegen/external-reference-encoder.h",
"src/codegen/external-reference-table.h",
"src/codegen/external-reference.h",
"src/codegen/flush-instruction-cache.h",
"src/codegen/handler-table.h",
Reland "[codegen] Add static interface descriptors" This is a reland of ae0752df1b84d8c53cc7b2af71013a9e678a9c6e Reland fixes: * Remove UNREACHABLE() from constexpr switch, since we don't have a CONSTEXPR_UNREACHABLE() (it's ok, the switch is exhaustive for the enum anyway). * Fix IsRegisterArray trait to use public inheritance and size_t for std::array size. Original change's description: > [codegen] Add static interface descriptors > > Add a new CRTP StaticCallInterfaceDescriptor class, which provides > static constexpr getters for a descriptor's registers, parameter counts, > and so on. Each CallInterfaceDescriptor subclass is changed to extend > StaticCallInterfaceDescriptor, with StaticCallInterfaceDescriptor itself > extending CallInterfaceDescriptor to still provide a dynamic lookup > where needed. > > StaticCallInterfaceDescriptor provides a couple of customisation points, > where it reads its CRTP derived descriptor's static fields and > functions, with default fallbacks where appropriate. With these > customisation points, the definition of CallInterfaceDescriptor > subclasses is simplified to: > > a) Providing parameter names (as before) > b) Providing parameter types (as before) > c) Optionally setting flags (like kNoContext or kAllowVarArgs) as > static booleans on the class. > d) Optionally providing a `registers()` method that returns a > std::array<Register, N> of registers that may be used for > parameters (if not provided, this defaults to the implementation > specific default register set). > > Parameter registers (and register count) are automagically set based on > the number of parameters and number of given registers, with extra magic > to ignore no_reg registers (to reduce ia32 special casing). The > CallInterfaceDescriptorData is initialized based on these static > functions, rather than manual per-descriptor initializers. > > This allows us to skip loading descriptors dynamically for CallBuiltin > in Sparkplug, and instead lets us use a bit of template magic to > statically set up arguments for the calls. Any other users of statically > known descriptors will also benefit, thanks to C++ picking the static > methods over the dynamic methods on the base class when available. > > Because we can remove various virtual functions and trigger heavier > inlining of constantly known values, binary size slightly decreases with > this change. > > Note that torque-generated descriptors are changed to use the same magic, > rather than having Torque-specific magic, for consistency. > > Bug: v8:11420 > Change-Id: Icc5e238b6313a08734feb564204a13226b450c22 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814518 > Auto-Submit: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73996} TBR=nicohartmann@chromium.org,clemensb@chromium.org,ishell@chromium.org,clemensb@chromium.org Bug: v8:11420 Change-Id: Icd1f6cdb3c178e74460044b1e9623139929ceba8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2831872 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74010}
2021-04-16 14:52:06 +00:00
"src/codegen/interface-descriptors-inl.h",
"src/codegen/interface-descriptors.h",
"src/codegen/label.h",
"src/codegen/machine-type.h",
"src/codegen/macro-assembler-inl.h",
"src/codegen/macro-assembler.h",
"src/codegen/maglev-safepoint-table.h",
"src/codegen/optimized-compilation-info.h",
"src/codegen/pending-optimization-table.h",
"src/codegen/register-arch.h",
"src/codegen/register-base.h",
"src/codegen/register-configuration.h",
"src/codegen/register.h",
"src/codegen/reglist-base.h",
"src/codegen/reglist.h",
"src/codegen/reloc-info.h",
"src/codegen/safepoint-table-base.h",
"src/codegen/safepoint-table.h",
"src/codegen/script-details.h",
"src/codegen/signature.h",
"src/codegen/source-position-table.h",
"src/codegen/source-position.h",
"src/codegen/tick-counter.h",
"src/codegen/tnode.h",
"src/codegen/turbo-assembler.h",
"src/codegen/unoptimized-compilation-info.h",
"src/common/assert-scope.h",
"src/common/checks.h",
"src/common/code-memory-access-inl.h",
"src/common/code-memory-access.h",
"src/common/high-allocation-throughput-scope.h",
"src/common/message-template.h",
"src/common/operation.h",
"src/common/ptr-compr-inl.h",
"src/common/ptr-compr.h",
"src/compiler-dispatcher/lazy-compile-dispatcher.h",
"src/compiler-dispatcher/optimizing-compile-dispatcher.h",
"src/compiler/access-builder.h",
"src/compiler/access-info.h",
"src/compiler/add-type-assertions-reducer.h",
"src/compiler/all-nodes.h",
"src/compiler/allocation-builder-inl.h",
"src/compiler/allocation-builder.h",
"src/compiler/backend/bitcast-elider.h",
"src/compiler/backend/code-generator-impl.h",
"src/compiler/backend/code-generator.h",
"src/compiler/backend/frame-elider.h",
"src/compiler/backend/gap-resolver.h",
"src/compiler/backend/instruction-codes.h",
"src/compiler/backend/instruction-scheduler.h",
"src/compiler/backend/instruction-selector-impl.h",
"src/compiler/backend/instruction-selector.h",
"src/compiler/backend/instruction.h",
"src/compiler/backend/jump-threading.h",
"src/compiler/backend/mid-tier-register-allocator.h",
"src/compiler/backend/move-optimizer.h",
"src/compiler/backend/register-allocation.h",
"src/compiler/backend/register-allocator-verifier.h",
"src/compiler/backend/register-allocator.h",
"src/compiler/backend/spill-placer.h",
"src/compiler/backend/unwinding-info-writer.h",
"src/compiler/basic-block-instrumentor.h",
Reland^2 [compiler] Simplify "==0" branches in MachineOperatorReducer This is a reland of 6b690a6b48e418d474bfda4cc536fde087e61515. The previous version of this CL was a bit too aggressive in the duplication of branch conditions. This caused an increase in register pressure in some cases, thus reducing performance. In fact, duplicating branch conditions that require an "== 0" to be added provides no benefits. We are thus now a bit less aggressive, and only duplicate comparisons. Original change's description: > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer > > This is a reland of 48b443f69291a4b0dde9db36aae11c29c3c0cb2d. > > While fixing the initial CL, we stumbled upon a few bugs that > we had to fix: > > - CommonOperatorReducer and SimplifiedOperatorReducer were applied > before and after SimplifiedLowering, but always assumed that it > was before SimplifiedLowering, and thus had the wrong semantics > for branches in some cases. They now have an added parameter to > know which semantics of branch they should use. > > - The lowering of StaticAssert was wrong and could leave kHeapConstant > in the assert (instead of machine Booleans). > > Original change's description: > > [compiler] Simplify "==0" branches in MachineOperatorReducer > > > > Bug: v8:12484 > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Owners-Override: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#79379} > > Bug: v8:12484 > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79528} Bug: v8:12484 Change-Id: I31f575a59811a83c7c1acb4c14bf5ded63a8f536 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540102 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#79560}
2022-03-21 16:55:30 +00:00
"src/compiler/branch-condition-duplicator.h",
"src/compiler/branch-elimination.h",
"src/compiler/bytecode-analysis.h",
"src/compiler/bytecode-graph-builder.h",
"src/compiler/bytecode-liveness-map.h",
"src/compiler/checkpoint-elimination.h",
"src/compiler/code-assembler.h",
"src/compiler/common-node-cache.h",
"src/compiler/common-operator-reducer.h",
"src/compiler/common-operator.h",
"src/compiler/compilation-dependencies.h",
"src/compiler/compiler-source-position-table.h",
"src/compiler/constant-folding-reducer.h",
"src/compiler/control-equivalence.h",
"src/compiler/control-flow-optimizer.h",
"src/compiler/control-path-state.h",
"src/compiler/csa-load-elimination.h",
"src/compiler/dead-code-elimination.h",
"src/compiler/decompression-optimizer.h",
"src/compiler/diamond.h",
"src/compiler/effect-control-linearizer.h",
"src/compiler/escape-analysis-reducer.h",
"src/compiler/escape-analysis.h",
"src/compiler/fast-api-calls.h",
"src/compiler/feedback-source.h",
"src/compiler/frame-states.h",
"src/compiler/frame.h",
"src/compiler/functional-list.h",
"src/compiler/globals.h",
"src/compiler/graph-assembler.h",
"src/compiler/graph-reducer.h",
"src/compiler/graph-trimmer.h",
"src/compiler/graph-visualizer.h",
"src/compiler/graph-zone-traits.h",
"src/compiler/graph.h",
"src/compiler/heap-refs.h",
"src/compiler/js-call-reducer.h",
"src/compiler/js-context-specialization.h",
"src/compiler/js-create-lowering.h",
"src/compiler/js-generic-lowering.h",
"src/compiler/js-graph.h",
"src/compiler/js-heap-broker.h",
"src/compiler/js-inlining-heuristic.h",
"src/compiler/js-inlining.h",
"src/compiler/js-intrinsic-lowering.h",
"src/compiler/js-native-context-specialization.h",
"src/compiler/js-operator.h",
"src/compiler/js-type-hint-lowering.h",
"src/compiler/js-typed-lowering.h",
"src/compiler/late-escape-analysis.h",
"src/compiler/linkage.h",
"src/compiler/load-elimination.h",
"src/compiler/loop-analysis.h",
"src/compiler/loop-peeling.h",
"src/compiler/loop-unrolling.h",
"src/compiler/loop-variable-optimizer.h",
"src/compiler/machine-graph-verifier.h",
"src/compiler/machine-graph.h",
"src/compiler/machine-operator-reducer.h",
"src/compiler/machine-operator.h",
"src/compiler/map-inference.h",
"src/compiler/memory-lowering.h",
"src/compiler/memory-optimizer.h",
"src/compiler/node-aux-data.h",
"src/compiler/node-cache.h",
"src/compiler/node-marker.h",
"src/compiler/node-matchers.h",
"src/compiler/node-observer.h",
"src/compiler/node-origin-table.h",
"src/compiler/node-properties.h",
"src/compiler/node.h",
"src/compiler/opcodes.h",
"src/compiler/operation-typer.h",
"src/compiler/operator-properties.h",
"src/compiler/operator.h",
"src/compiler/osr.h",
"src/compiler/per-isolate-compiler-cache.h",
"src/compiler/persistent-map.h",
"src/compiler/pipeline-statistics.h",
"src/compiler/pipeline.h",
"src/compiler/processed-feedback.h",
"src/compiler/property-access-builder.h",
"src/compiler/raw-machine-assembler.h",
"src/compiler/redundancy-elimination.h",
"src/compiler/refs-map.h",
"src/compiler/representation-change.h",
"src/compiler/schedule.h",
"src/compiler/scheduler.h",
"src/compiler/select-lowering.h",
"src/compiler/simplified-lowering-verifier.h",
"src/compiler/simplified-lowering.h",
"src/compiler/simplified-operator-reducer.h",
"src/compiler/simplified-operator.h",
"src/compiler/state-values-utils.h",
"src/compiler/store-store-elimination.h",
"src/compiler/turboshaft/assembler.h",
"src/compiler/turboshaft/assert-types-reducer.h",
"src/compiler/turboshaft/branch-elimination-reducer.h",
"src/compiler/turboshaft/decompression-optimization.h",
"src/compiler/turboshaft/deopt-data.h",
"src/compiler/turboshaft/fast-hash.h",
"src/compiler/turboshaft/graph-builder.h",
"src/compiler/turboshaft/graph-visualizer.h",
"src/compiler/turboshaft/graph.h",
"src/compiler/turboshaft/index.h",
"src/compiler/turboshaft/late-escape-analysis-reducer.h",
"src/compiler/turboshaft/layered-hash-map.h",
"src/compiler/turboshaft/machine-optimization-reducer.h",
"src/compiler/turboshaft/memory-optimization.h",
"src/compiler/turboshaft/operation-matching.h",
"src/compiler/turboshaft/operations.h",
"src/compiler/turboshaft/optimization-phase.h",
"src/compiler/turboshaft/recreate-schedule.h",
"src/compiler/turboshaft/representations.h",
"src/compiler/turboshaft/select-lowering-reducer.h",
"src/compiler/turboshaft/sidetable.h",
"src/compiler/turboshaft/simplify-tf-loops.h",
"src/compiler/turboshaft/snapshot-table.h",
"src/compiler/turboshaft/type-inference-reducer.h",
"src/compiler/turboshaft/types.h",
"src/compiler/turboshaft/utils.h",
"src/compiler/turboshaft/value-numbering-reducer.h",
"src/compiler/turboshaft/variable-reducer.h",
"src/compiler/type-cache.h",
"src/compiler/type-narrowing-reducer.h",
"src/compiler/typed-optimization.h",
"src/compiler/typer.h",
"src/compiler/types.h",
"src/compiler/use-info.h",
"src/compiler/value-numbering-reducer.h",
"src/compiler/verifier.h",
"src/compiler/write-barrier-kind.h",
"src/compiler/zone-stats.h",
"src/date/date.h",
"src/date/dateparser-inl.h",
"src/date/dateparser.h",
"src/debug/debug-coverage.h",
"src/debug/debug-evaluate.h",
"src/debug/debug-frames.h",
"src/debug/debug-interface.h",
"src/debug/debug-property-iterator.h",
"src/debug/debug-scope-iterator.h",
"src/debug/debug-scopes.h",
"src/debug/debug-stack-trace-iterator.h",
"src/debug/debug.h",
"src/debug/interface-types.h",
"src/debug/liveedit-diff.h",
"src/debug/liveedit.h",
Reland "Move deoptimizer files" This reverts commit a7695520556665ba73ab02c497ab73b162a5fb13. Reason for revert: Was not the culprit. Original change's description: > Revert "Move deoptimizer files" > > This reverts commit 61523c45a335fe3be76498e0b16bf8e7aec0d058. > > Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/20396 > > Original change's description: > > Move deoptimizer files > > > > Bug: v8:9247 > > Change-Id: I6287907edb8a36225bfa9fe864305ea59c20dd8b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617667 > > Commit-Queue: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61648} > > TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org > > Change-Id: Icf258f7bc409ef0c360cfa82029bfc45a41dc75f > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:9247 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619749 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61650} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org Change-Id: Ic2aa07ccd08b6070222ec7a65b92b7afb9db484c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619753 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61652}
2019-05-20 13:01:00 +00:00
"src/deoptimizer/deoptimize-reason.h",
"src/deoptimizer/deoptimized-frame-info.h",
Reland "Move deoptimizer files" This reverts commit a7695520556665ba73ab02c497ab73b162a5fb13. Reason for revert: Was not the culprit. Original change's description: > Revert "Move deoptimizer files" > > This reverts commit 61523c45a335fe3be76498e0b16bf8e7aec0d058. > > Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/20396 > > Original change's description: > > Move deoptimizer files > > > > Bug: v8:9247 > > Change-Id: I6287907edb8a36225bfa9fe864305ea59c20dd8b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1617667 > > Commit-Queue: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#61648} > > TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org > > Change-Id: Icf258f7bc409ef0c360cfa82029bfc45a41dc75f > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:9247 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619749 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Yang Guo <yangguo@chromium.org> > Cr-Commit-Position: refs/heads/master@{#61650} TBR=yangguo@chromium.org,mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org Change-Id: Ic2aa07ccd08b6070222ec7a65b92b7afb9db484c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9247 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619753 Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61652}
2019-05-20 13:01:00 +00:00
"src/deoptimizer/deoptimizer.h",
"src/deoptimizer/frame-description.h",
"src/deoptimizer/materialized-object-store.h",
"src/deoptimizer/translated-state.h",
"src/deoptimizer/translation-array.h",
"src/deoptimizer/translation-opcode.h",
"src/diagnostics/basic-block-profiler.h",
"src/diagnostics/code-tracer.h",
"src/diagnostics/compilation-statistics.h",
"src/diagnostics/disasm.h",
"src/diagnostics/disassembler.h",
"src/diagnostics/eh-frame.h",
"src/diagnostics/gdb-jit.h",
"src/diagnostics/perf-jit.h",
"src/diagnostics/unwinder.h",
"src/execution/arguments-inl.h",
"src/execution/arguments.h",
"src/execution/clobber-registers.h",
Reland "[profiler] Surface VM & Embedder State" This is a reland of 2d087f237eadd78f5545548675642f013fdfe675 The changes are : * Fix redundant reinterpret_cast in test file for MSVC failure https://crbug.com/v8/12476 * Fix flaky test https://crbug.com/v8/12475 If a sample is captured during a GC, no embedder context is obtained defaulting to EMPTY. This is the expected behavior, made it in clear in implementation and in test. * Synchronized the embedder context filter behavior with existing native context filter. Original change's description: > Add APIs to surface VMState and new EmbedderState to CpuProfile samples. > > EmbedderState: > * An EmbedderState is defined as a value uint8_t and a v8::context used > for filtering. > * EmbedderStates are stack allocated by the embedder, construction and > destruction set/unset the state to the isolate thread local top. > * A v8::context is used to filter states that are added to a CpuProfile, > if the CpuProfile do not have a ContextFilter set or if contexts do not > match, state defaults to Empty. > > * v8:StateTag is already propagated all the way to a Sample, simply add > an API to surface it. > > VMState: > Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e > Bug: chromium:1263871 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072 > Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78250} Bug: chromium:1263871 Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037 Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78281}
2021-12-07 07:28:08 +00:00
"src/execution/embedder-state.h",
Reland^2 "[fastcall] Enable float support on arm64 simulator"" This is a reland of d7c3f1cd8a2450afdfe592f87c67cead3a00b88e. It fixes a build failure on native arm64. Original change's description: > Reland "[fastcall] Enable float support on arm64 simulator" > > This is a reland of b9ddcbc86f76fb393e9343162348e976ae6d3a33 > > The original CL was reverted due to an MSAN issue, that is fixed by > moving the signature mapping onto the Isolate (instead of having > per-thread storage, which got invalid on multithreaded compilation). > > This CL also contains fixes for the Bazel config and for a data race > when obtaining the PerIsolateSimulatorData. > > Original change's description: > > [fastcall] Enable float support on arm64 simulator > > > > This CL adds support for handling calls to C functions with arbitrary > > signatures on the arm64 simulator. It adds infrastructure for > > encoding the signature data from CallDescriptor and FunctionInfo > > classes into a compact representation, stored in the simulator and > > called EncodedCSignature. > > > > Design doc: > > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit > > > > This CL is a follow up on the native support added in > > https://chromium-review.googlesource.com/c/v8/v8/+/3182232 > > and is partially based on the previous attempt: > > https://chromium-review.googlesource.com/c/v8/v8/+/2343072 > > > > Bug: chromium:1052746 > > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486 > > Commit-Queue: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#77744} > > Bug: chromium:1052746, chromium:1267854 > Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78018} Bug: chromium:1052746, chromium:1267854 Change-Id: Ib495573569a6c930b8f9e5f1fe7ff46eb57a0aa7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295461 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#78063}
2021-11-22 17:10:53 +00:00
"src/execution/encoded-c-signature.h",
"src/execution/execution.h",
"src/execution/frame-constants.h",
"src/execution/frames-inl.h",
"src/execution/frames.h",
"src/execution/futex-emulation.h",
"src/execution/interrupts-scope.h",
"src/execution/isolate-data.h",
"src/execution/isolate-inl.h",
"src/execution/isolate-utils-inl.h",
"src/execution/isolate-utils.h",
"src/execution/isolate.h",
[offthread] Change OffThreadIsolate to LocalIsolate This patch introduces a new LocalIsolate and LocalFactory, which use LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows us to remove those classes, as well as the related OffThreadSpace, OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle. OffThreadLogger becomes LocalLogger. LocalHeap behaves more like Heap than OffThreadHeap did, so this allows us to additionally remove the concept of "Finish" and "Publish" that the OffThreadIsolate had, and allows us to internalize strings directly with the newly-concurrent string table (where the implementation can now move to FactoryBase). This patch also removes the off-thread support from the deserializer entirely, as well as removing the LocalIsolateWrapper which allowed run-time distinction between Isolate and OffThreadIsolate. LocalHeap doesn't support the reservation model used by the deserializer, and we will likely move the deserializer to use LocalIsolate unconditionally once we figure out the details of how to do this. Bug: chromium:1011762 Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990 Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69397}
2020-08-13 12:12:17 +00:00
"src/execution/local-isolate-inl.h",
"src/execution/local-isolate.h",
"src/execution/messages.h",
"src/execution/microtask-queue.h",
Reland "[arm64] Protect return addresses stored on stack" This is a reland of 137bfe47c9af56dcf8466e2736579616e51b86df 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/+/2051958 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Cr-Commit-Position: refs/heads/master@{#66254}
2020-02-12 11:45:31 +00:00
"src/execution/pointer-authentication.h",
"src/execution/protectors-inl.h",
"src/execution/protectors.h",
"src/execution/shared-mutex-guard-if-off-thread.h",
"src/execution/simulator-base.h",
"src/execution/simulator.h",
"src/execution/stack-guard.h",
"src/execution/thread-id.h",
"src/execution/thread-local-top.h",
"src/execution/tiering-manager.h",
"src/execution/v8threads.h",
"src/execution/vm-state-inl.h",
"src/execution/vm-state.h",
"src/extensions/cputracemark-extension.h",
"src/extensions/externalize-string-extension.h",
"src/extensions/gc-extension.h",
"src/extensions/ignition-statistics-extension.h",
"src/extensions/statistics-extension.h",
"src/extensions/trigger-failure-extension.h",
"src/handles/global-handles-inl.h",
"src/handles/global-handles.h",
"src/handles/handles-inl.h",
"src/handles/handles.h",
"src/handles/local-handles-inl.h",
"src/handles/local-handles.h",
"src/handles/maybe-handles-inl.h",
"src/handles/maybe-handles.h",
"src/handles/persistent-handles.h",
"src/handles/shared-object-conveyor-handles.h",
"src/handles/traced-handles.h",
"src/heap/allocation-observer.h",
"src/heap/allocation-result.h",
"src/heap/allocation-stats.h",
"src/heap/array-buffer-sweeper.h",
"src/heap/base-space.h",
"src/heap/basic-memory-chunk.h",
"src/heap/code-object-registry.h",
"src/heap/code-range.h",
"src/heap/code-stats.h",
"src/heap/collection-barrier.h",
Reland "[heap] Skip ro-space from heap iterators, add CombinedHeapIterator." Code relocation info is now always allocated in old-space. Before relocation info allocated for placeholders and builtins (which get replaced with trampolines in nosnap builds) would become unreachable. Since read-only space is not GCed and ReadOnlyHeapIterator doesn't check for reachability, ValidateSnapshot would fail finding unreachable objects returned by ReadOnlyHeapIterator. Because trampoline relocation info gets replaced with canonical one, this only affects no-embdded-builtins nosnap builds, which don't get much benefit from read-only relocation info anyway. A new check has been added to the read-only deserializer to verify that every read-only object is reachable at mksnapshot-time. The CombinedHeapIterator iteration order was changed to iterate over read-only space first, because that's how HeapIterator worked. This is a reland of 3d1d8eae772877422e7082571e77c326e7e8e60a Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} Bug: v8:7464 Change-Id: I49ae070955b77956962334a84f762ab29052d5ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513 Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#61185}
2019-05-02 15:35:51 +00:00
"src/heap/combined-heap.h",
"src/heap/concurrent-allocator-inl.h",
"src/heap/concurrent-allocator.h",
"src/heap/concurrent-marking.h",
"src/heap/cppgc-js/cpp-heap.h",
"src/heap/cppgc-js/cpp-marking-state-inl.h",
"src/heap/cppgc-js/cpp-marking-state.h",
Reland "cppgc-js: Add snapshot for C++ objects" This reverts commit fba14bde5fa0ac26ee6732677acbc3f21e135c74. Reland fixes: - const vector<const string> -> const vector<string> Original message: The following implements a snapshotting algorithm for C++ objects that also filters strongly-connected components (SCCs) of only "hidden" objects that are not (transitively) referencing any non-hidden objects. C++ objects come in two versions. a. Named objects that have been assigned a name through NameProvider. b. Unnamed objects, that are potentially hidden if the build configuration requires Oilpan to hide such names. Hidden objects have their name set to NameProvider::kHiddenName. The main challenge for the algorithm is to avoid blowing up the final object graph with hidden nodes that do not carry information. For that reason, the algorithm filters SCCs of only hidden objects, e.g.: ... -> (object) -> (object) -> (hidden) -> (hidden) In this case the (hidden) objects are filtered from the graph. The trickiest part is maintaining visibility state for objects referencing other objects that are currently being processed. Main algorithm idea (two passes): 1. First pass marks all non-hidden objects and those that transitively reach non-hidden objects as visible. Details: - Iterate over all objects. - If object is non-hidden mark it as visible and also mark parent as visible if needed. - If object is hidden, traverse children as DFS to find non-hidden objects. Post-order process the objects and mark those objects as visible that have child nodes that are visible themselves. - Maintain an epoch counter (StateStorage::state_count_) to allow deferring the visibility decision to other objects in the same SCC. This is similar to the "lowlink" value in Tarjan's algorithm for SCC. - After the first pass it is guaranteed that all deferred visibility decisions can be resolved. 2. Second pass adds nodes and edges for all visible objects. - Upon first checking the visibility state of an object, all deferred visibility states are resolved. For practical reasons, the recursion is transformed into an iteration. We do not use plain Tarjan's algorithm to avoid another pass over all nodes to create SCCs. Follow ups: 1. Adding wrapper nodes for cpp objects that are wrappables for V8 wrappers. 2. Adding detachedness information. Bug: chromium:1056170 Change-Id: Ib47df5c912c57d644d052f209276e9d926cece0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2480362 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70577}
2020-10-16 15:05:08 +00:00
"src/heap/cppgc-js/cpp-snapshot.h",
"src/heap/cppgc-js/cross-heap-remembered-set.h",
Reland "cppgc-js: Concurrently process v8::TracedReference" This is a reland of commit 1f0d7d207260e32f17931b1aa89e71d490f9d460 The fix merges concurrent marking tasks when marking in the atomic pause. Without the fix, Oilpan markers would continue running concurrently, possibly discovering new V8 objects. This violates the assumption that the final transitive closure runs on a single thread. Original change's description: > cppgc-js: Concurrently process v8::TracedReference > > Adds concurrent marking for reaching through v8::TracedReference. > Before this CL, a v8::TracedReference would always be processed on the > main thread by pushing a callback for each encountered reference. > > This CL now wires up concurrent handling for such references. In particular: > - Global handles are already marked as well and not repurposed during > the same GC cycle. > - Since global handles are not repurposed, it is enough to > double-deref to the V8 object, checking for possible null pointers. > - The bitmap for global handle flags is mostly non-atomic, with the > markbit being the exception. > - Finally, all state is wired up in CppHeap. Concurrent markers keep > their own local worklist while the mutator marker directly pushes to > the worklist owned by V8. > > Bug: v8:12600 > Change-Id: Ia67dbd18a57dbcccf4dfb9ccfdb9ee438d27fe71 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516255 > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79736} Bug: v8:12600 Change-Id: I8545041b2c7b3daf7ecea7e3a100e27534e9b8b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571887 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#79919}
2022-04-11 13:24:03 +00:00
"src/heap/cppgc-js/unified-heap-marking-state-inl.h",
"src/heap/cppgc-js/unified-heap-marking-state.h",
"src/heap/cppgc-js/unified-heap-marking-verifier.h",
"src/heap/cppgc-js/unified-heap-marking-visitor.h",
"src/heap/embedder-tracing-inl.h",
"src/heap/embedder-tracing.h",
"src/heap/evacuation-allocator-inl.h",
"src/heap/evacuation-allocator.h",
"src/heap/evacuation-verifier-inl.h",
"src/heap/evacuation-verifier.h",
"src/heap/factory-base-inl.h",
[offthread] Add OffThreadFactory Introduce OffThreadFactory with initial string construction support. The OffThreadFactory shares with Factory a new CRTP base class, called FactoryBase. Methods in FactoryBase return a FactoryHandle<Factory, T> alias, which is Handle<T> for normal Factory and a new OffThreadHandle<T> for OffThreadFactory. OffThreadHandle<T> behaves like Handle<T>, except it stores the object in-line rather than needing external storage. Any shared factory methods are moved into FactoryBase, which uses CRTP to call the sub-class's AllocateRaw method (plus a few more customization points which need Isolate access on the main thread). Methods that used to take an Isolate or Factory, and are needed off the main thread, are now expected to be templated on the factory type and to use the appropriate handle. Once an OffThreadFactory has finished being used (e.g. off-thread compilation completed) its pages are "Published" into the main-thread Heap. To deal with string internalization without creating a bunch of ThinStrings, this is done in two stages: 1. 'FinishOffThread': The off-thread pages are walked to collect all slots pointing to "internalized" strings. After this is called it is invalid to allocate any more objects with the factory. 2. 'Publish': On the main thread, we transform these slots into <Handle to holder, offset> pairs, then for each saved slot re-internalize its string and update the slot to point to the internalized string. Bug: chromium:1011762 Change-Id: I008a694da3c357de34362bd86fe7e1f46b535d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992434 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65787}
2020-01-15 11:47:41 +00:00
"src/heap/factory-base.h",
"src/heap/factory-inl.h",
"src/heap/factory.h",
"src/heap/finalization-registry-cleanup-task.h",
"src/heap/free-list-inl.h",
"src/heap/free-list.h",
"src/heap/gc-callbacks.h",
"src/heap/gc-idle-time-handler.h",
"src/heap/gc-tracer-inl.h",
"src/heap/gc-tracer.h",
"src/heap/heap-allocator-inl.h",
"src/heap/heap-allocator.h",
"src/heap/heap-controller.h",
"src/heap/heap-inl.h",
"src/heap/heap-layout-tracer.h",
"src/heap/heap-write-barrier-inl.h",
"src/heap/heap-write-barrier.h",
"src/heap/heap.h",
"src/heap/incremental-marking-inl.h",
"src/heap/incremental-marking-job.h",
"src/heap/incremental-marking.h",
"src/heap/index-generator.h",
"src/heap/invalidated-slots-inl.h",
"src/heap/invalidated-slots.h",
"src/heap/large-spaces.h",
"src/heap/linear-allocation-area.h",
"src/heap/list.h",
"src/heap/local-factory-inl.h",
[offthread] Change OffThreadIsolate to LocalIsolate This patch introduces a new LocalIsolate and LocalFactory, which use LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows us to remove those classes, as well as the related OffThreadSpace, OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle. OffThreadLogger becomes LocalLogger. LocalHeap behaves more like Heap than OffThreadHeap did, so this allows us to additionally remove the concept of "Finish" and "Publish" that the OffThreadIsolate had, and allows us to internalize strings directly with the newly-concurrent string table (where the implementation can now move to FactoryBase). This patch also removes the off-thread support from the deserializer entirely, as well as removing the LocalIsolateWrapper which allowed run-time distinction between Isolate and OffThreadIsolate. LocalHeap doesn't support the reservation model used by the deserializer, and we will likely move the deserializer to use LocalIsolate unconditionally once we figure out the details of how to do this. Bug: chromium:1011762 Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990 Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69397}
2020-08-13 12:12:17 +00:00
"src/heap/local-factory.h",
"src/heap/local-heap-inl.h",
"src/heap/local-heap.h",
"src/heap/mark-compact-inl.h",
"src/heap/mark-compact.h",
"src/heap/marking-barrier-inl.h",
"src/heap/marking-barrier.h",
"src/heap/marking-state-inl.h",
"src/heap/marking-state.h",
"src/heap/marking-visitor-inl.h",
"src/heap/marking-visitor.h",
"src/heap/marking-worklist-inl.h",
"src/heap/marking-worklist.h",
"src/heap/marking.h",
"src/heap/memory-allocator.h",
"src/heap/memory-chunk-inl.h",
"src/heap/memory-chunk-layout.h",
"src/heap/memory-chunk.h",
"src/heap/memory-measurement-inl.h",
"src/heap/memory-measurement.h",
"src/heap/memory-reducer.h",
"src/heap/new-spaces-inl.h",
"src/heap/new-spaces.h",
"src/heap/object-stats.h",
"src/heap/objects-visiting-inl.h",
"src/heap/objects-visiting.h",
"src/heap/paged-spaces-inl.h",
"src/heap/paged-spaces.h",
Reland "Reland "[Heap] ScavengerCollector use Jobs."" This is a reland of 92f815a80d8b8d71d6f1c2f37875fad6dcfcf96c Safe to reland as-is with task id lifetime fix in https://chromium-review.googlesource.com/c/v8/v8/+/2437005 Original change's description: > Reland "[Heap] ScavengerCollector use Jobs." > > This is a reland of 9e8c54f8301c75d61904abcd372a0d5c33d70c67 > Safe to reland as-is with fix in AcquireTaskId > https://chromium-review.googlesource.com/c/v8/v8/+/2401964 > > Additional changes are made in the reland: > -TRACE_GC is be split for background/foreground scope. > -New IndexGenerator is used for dynamic work assignement. > > Original change's description: > > [Heap] ScavengerCollector use Jobs. > > > > No yielding is necessary since the main thread Join()s. > > > > max concurrency is determined based on either > > remaining_memory_chunks_ or global pool size > > (copied_list_ + promotion_list_) > > > > Change-Id: Ie30fa86c44d3224b04df5d79569bce126ce7d96b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2354390 > > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#69746} > > Change-Id: Id9d7a5bf3b2337ae4cf1e76770f4b14ebb8ca256 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2399041 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70135} Change-Id: Id0451b6eca9a125c7695d251d1a7d813e0664dd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2432071 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70238}
2020-09-30 15:41:56 +00:00
"src/heap/parallel-work-item.h",
Reland "[heap] Introduce LocalIsolate for main thread" This is a reland of e95e1b62342659b8c7dda5ce3d3a2f13f554342d After landing https://crrev.com/c/2546682, this CL can be relanded without changes. Original change's description: > [heap] Introduce LocalIsolate for main thread > > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is > kept alive during the whole lifetime of the Isolate. The main thread > LocalIsolate starts in the Running state in contrast to the background > thread LocalIsolates (those start in Parked). > > Code paths in Turbofan that used to create a LocalIsolate on the main > thread can now simply use the main thread LocalIsolate. > > LocalIsolate for the main thread will help in reducing differences > between the main and background threads. The goal is that the main > thread behaves more like a background thread. > > The main thread LocalIsolate should also make it simpler to share code > between main thread and background threads by using LocalIsolate for > both. > > Bug: v8:10315 > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593 > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71226} Bug: v8:10315 Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656 TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71274}
2020-11-17 10:16:09 +00:00
"src/heap/parked-scope.h",
"src/heap/pretenuring-handler-inl.h",
"src/heap/pretenuring-handler.h",
"src/heap/progress-bar.h",
"src/heap/read-only-heap-inl.h",
"src/heap/read-only-heap.h",
"src/heap/read-only-spaces.h",
"src/heap/remembered-set-inl.h",
"src/heap/remembered-set.h",
"src/heap/safepoint.h",
"src/heap/scavenge-job.h",
"src/heap/scavenger-inl.h",
"src/heap/scavenger.h",
"src/heap/slot-set.h",
"src/heap/spaces-inl.h",
"src/heap/spaces.h",
"src/heap/stress-marking-observer.h",
"src/heap/stress-scavenge-observer.h",
"src/heap/sweeper.h",
"src/heap/traced-handles-marking-visitor.h",
"src/heap/weak-object-worklists.h",
"src/ic/call-optimization.h",
"src/ic/handler-configuration-inl.h",
"src/ic/handler-configuration.h",
"src/ic/ic-inl.h",
"src/ic/ic-stats.h",
"src/ic/ic.h",
"src/ic/stub-cache.h",
"src/init/bootstrapper.h",
"src/init/heap-symbols.h",
"src/init/icu_util.h",
"src/init/isolate-allocator.h",
"src/init/setup-isolate.h",
"src/init/startup-data-util.h",
"src/init/v8.h",
"src/interpreter/block-coverage-builder.h",
"src/interpreter/bytecode-array-builder.h",
"src/interpreter/bytecode-array-iterator.h",
"src/interpreter/bytecode-array-random-iterator.h",
"src/interpreter/bytecode-array-writer.h",
"src/interpreter/bytecode-decoder.h",
"src/interpreter/bytecode-flags.h",
"src/interpreter/bytecode-generator.h",
"src/interpreter/bytecode-jump-table.h",
"src/interpreter/bytecode-label.h",
"src/interpreter/bytecode-node.h",
[Interpreter] Optimize BytecodeArrayBuilder and BytecodeArrayWriter. This CL optimizes the code in BytecodeArrayBuilder and BytecodeArrayWriter by making the following main changes: - Move operand scale calculation out of BytecodeArrayWriter to the BytecodeNode constructor, where the decision on which operands are scalable can generally be statically decided by the compiler. - Move the maximum register calculation out of BytecodeArrayWriter and into BytecodeRegisterOptimizer (which is the only place outside BytecodeGenerator which updates which registers are used). This avoids the BytecodeArrayWriter needing to know the operand types of a node as it writes it. - Modify EmitBytecodes to use individual push_backs rather than building a buffer and calling insert, since this turns out to be faster. - Initialize BytecodeArrayWriter's bytecode vector by reserving 512 bytes, - Make common functions in Bytecodes constexpr so that they can be statically calculated by the compiler. - Move common functions and constructors in Bytecodes and BytecodeNode to the header so that they can be inlined. - Change large static switch statements in Bytecodes to const array lookups, and move to the header to allow inlining. I also took the opportunity to remove a number of unused helper functions, and rework some others for consistency. This reduces the percentage of time spent in making BytecodeArrays in CodeLoad from ~15% to ~11% according to perf. The CoadLoad score increase by around 2%. BUG=v8:4280 Committed: https://crrev.com/b11a8b4d41bf09d6b3d6cf214fe3fb61faf01a64 Review-Url: https://codereview.chromium.org/2351763002 Cr-Original-Commit-Position: refs/heads/master@{#39599} Cr-Commit-Position: refs/heads/master@{#39637}
2016-09-22 16:34:16 +00:00
"src/interpreter/bytecode-operands.h",
"src/interpreter/bytecode-register-allocator.h",
"src/interpreter/bytecode-register-optimizer.h",
"src/interpreter/bytecode-register.h",
"src/interpreter/bytecode-source-info.h",
"src/interpreter/bytecode-traits.h",
"src/interpreter/bytecodes.h",
"src/interpreter/constant-array-builder.h",
"src/interpreter/control-flow-builders.h",
"src/interpreter/handler-table-builder.h",
"src/interpreter/interpreter-generator.h",
"src/interpreter/interpreter-intrinsics.h",
"src/interpreter/interpreter.h",
"src/json/json-parser.h",
"src/json/json-stringifier.h",
"src/libsampler/sampler.h",
"src/logging/code-events.h",
"src/logging/counters-definitions.h",
Reland "[counters] Fix reentrant timers for V8.Execute" This is a reland of fffcbaea5568bec429fc52fdbc5429402a485ea4 Additional fixes: - Relax IsStarted DCHECKs in ElapsedTimer for paused_elapsed - Add LogEventStatus enum in the API for better testing - Rename Logger::StartEnd enum values to kXXX - Add additional NestedTimedHistogramScope tests Original change's description: > [counters] Fix reentrant timers for V8.Execute > > This CL fixes a long standing issue where reentering TimedHistograms > scopes would cause spurious measurements. Only the non-nested scopes > yielded correct results. > > Due to the changed numbers, the V8.Execute histogram is renamed to > V8.ExecuteMicroSeconds. Note that this histogram is also guarded > behind the --slow-histograms flag due to the additional overhead. > > Unlike before, it does no longer include time for external callbacks > and only measures self time. The following example illustrates the > new behaviour: > > 1. Enter V8: |--+.......+--| self-time: 4 units (reported) > 2. Exit V8 (callback): |-+...+-| self-time: 2 units (ignored) > 3. Re-enter V8: |---| self-time: 3 units (reported) > > This would result in 2 histogram entries with 4 time units for the first > V8 slice and 3 units for the nested part. Note that the callback time > itself is ignored. > > This CL attempts to clean up how TimedHistograms work: > - Histogram: the base class > - TimedHistograms: used for time-related histograms that are not nested > - NestedTimeHistograms: Extends TimedHistograms and is used for nested > histograms > > This CL changes Histograms to not measure time themselves. Measurements > happen in the *HistogramScopes: > - BaseTimedHistogramScope: Base functionality > - TimedHistogramScope: For non-nested measurements > - NestedTimedHistogramScope: For nested measurements > - PauseNestedTimedHistogramScope: Ignore time during a given scope. > This is used to pause timers during callbacks. > > Additional changes: > - ExternalCallbackScope now contains a PauseNestedTimedHistogramScope > and always sets VMState<EXTERNAL> > > Bug: v8:11946 > Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345 > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/master@{#76111} Bug: v8:11946 Change-Id: Ic2eef7456fbc245febcf780b23418f6ab0bebdb7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3080566 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#76180}
2021-08-09 14:30:16 +00:00
"src/logging/counters-scopes.h",
"src/logging/counters.h",
[offthread] Change OffThreadIsolate to LocalIsolate This patch introduces a new LocalIsolate and LocalFactory, which use LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows us to remove those classes, as well as the related OffThreadSpace, OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle. OffThreadLogger becomes LocalLogger. LocalHeap behaves more like Heap than OffThreadHeap did, so this allows us to additionally remove the concept of "Finish" and "Publish" that the OffThreadIsolate had, and allows us to internalize strings directly with the newly-concurrent string table (where the implementation can now move to FactoryBase). This patch also removes the off-thread support from the deserializer entirely, as well as removing the LocalIsolateWrapper which allowed run-time distinction between Isolate and OffThreadIsolate. LocalHeap doesn't support the reservation model used by the deserializer, and we will likely move the deserializer to use LocalIsolate unconditionally once we figure out the details of how to do this. Bug: chromium:1011762 Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990 Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69397}
2020-08-13 12:12:17 +00:00
"src/logging/local-logger.h",
"src/logging/log-file.h",
"src/logging/log-inl.h",
"src/logging/log.h",
"src/logging/metrics.h",
"src/logging/runtime-call-stats-scope.h",
"src/logging/runtime-call-stats.h",
"src/logging/tracing-flags.h",
"src/numbers/conversions-inl.h",
"src/numbers/conversions.h",
"src/numbers/hash-seed-inl.h",
"src/numbers/math-random.h",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/all-objects-inl.h",
"src/objects/allocation-site-inl.h",
"src/objects/allocation-site-scopes-inl.h",
"src/objects/allocation-site-scopes.h",
"src/objects/allocation-site.h",
"src/objects/api-callbacks-inl.h",
"src/objects/api-callbacks.h",
"src/objects/arguments-inl.h",
"src/objects/arguments.h",
Reland x6 [arraybuffer] Rearchitect backing store ownership This reverts commit 9da3483136b5e71e830ed9a9c34802ad8d605e58 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5aeba9ceb13f8bfc401c5ba2521c2207ffb > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63617}
2019-09-09 10:19:34 +00:00
"src/objects/backing-store.h",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/bigint-inl.h",
"src/objects/bigint.h",
"src/objects/call-site-info-inl.h",
"src/objects/call-site-info.h",
"src/objects/cell-inl.h",
"src/objects/cell.h",
"src/objects/code-inl.h",
"src/objects/code-kind.h",
"src/objects/code.h",
"src/objects/compilation-cache-table-inl.h",
"src/objects/compilation-cache-table.h",
"src/objects/compressed-slots-inl.h",
"src/objects/compressed-slots.h",
"src/objects/contexts-inl.h",
"src/objects/contexts.h",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/data-handler-inl.h",
"src/objects/data-handler.h",
"src/objects/debug-objects-inl.h",
"src/objects/debug-objects.h",
"src/objects/descriptor-array-inl.h",
"src/objects/descriptor-array.h",
"src/objects/dictionary-inl.h",
"src/objects/dictionary.h",
"src/objects/elements-inl.h",
"src/objects/elements-kind.h",
"src/objects/elements.h",
"src/objects/embedder-data-array-inl.h",
"src/objects/embedder-data-array.h",
"src/objects/embedder-data-slot-inl.h",
"src/objects/embedder-data-slot.h",
"src/objects/feedback-cell-inl.h",
"src/objects/feedback-cell.h",
"src/objects/feedback-vector-inl.h",
"src/objects/feedback-vector.h",
"src/objects/field-index-inl.h",
"src/objects/field-index.h",
"src/objects/field-type.h",
"src/objects/fixed-array-inl.h",
"src/objects/fixed-array.h",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/foreign-inl.h",
"src/objects/foreign.h",
"src/objects/free-space-inl.h",
"src/objects/free-space.h",
"src/objects/function-kind.h",
"src/objects/function-syntax-kind.h",
Revert "Revert "Fix GCC 7 build errors"" This reverts commit da607264dd699680cf18deb9db9cc8fd4650a730. Reason for revert: Looked wrong. The persistent layout test failures started in the next revision. The failure on the revision of the reverted CL was just a flake. Original change's description: > Revert "Fix GCC 7 build errors" > > This reverts commit c0f1ff2451b43cbc4b1ae9f668b616173877285a. > > Reason for revert: Speculative revert for layout test timeout: > https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/16402 > > Original change's description: > > Fix GCC 7 build errors > > > > BUG=chromium:691681 > > R=​franzih@chromium.org > > > > Change-Id: Id7e5698487f16dc217a804f6d3f24da7213c72b9 > > Reviewed-on: https://chromium-review.googlesource.com/530227 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#46045} > > TBR=adamk@chromium.org,franzih@chromium.org,mic.besace@gmail.com,verwaest@chromium.org > > Change-Id: I2119a87a95ed9eb88b7b32ae436edf28dfc86c16 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: chromium:691681 > Reviewed-on: https://chromium-review.googlesource.com/541227 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46065} TBR=adamk@chromium.org,machenbach@chromium.org,franzih@chromium.org,mic.besace@gmail.com,verwaest@chromium.org Change-Id: Ieee7f6b3b80d380e720206e7b43c4b580918b1d7 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:691681 Reviewed-on: https://chromium-review.googlesource.com/541228 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#46067}
2017-06-20 18:22:40 +00:00
"src/objects/hash-table-inl.h",
"src/objects/hash-table.h",
"src/objects/heap-number-inl.h",
"src/objects/heap-number.h",
"src/objects/heap-object-inl.h",
"src/objects/heap-object.h",
"src/objects/instance-type-inl.h",
"src/objects/instance-type.h",
"src/objects/internal-index.h",
"src/objects/js-array-buffer-inl.h",
"src/objects/js-array-buffer.h",
"src/objects/js-array-inl.h",
"src/objects/js-array.h",
"src/objects/js-atomics-synchronization-inl.h",
"src/objects/js-atomics-synchronization.h",
"src/objects/js-collection-inl.h",
"src/objects/js-collection-iterator-inl.h",
"src/objects/js-collection-iterator.h",
"src/objects/js-collection.h",
"src/objects/js-function-inl.h",
"src/objects/js-function.h",
"src/objects/js-generator-inl.h",
"src/objects/js-generator.h",
"src/objects/js-objects-inl.h",
"src/objects/js-objects.h",
"src/objects/js-promise-inl.h",
"src/objects/js-promise.h",
"src/objects/js-proxy-inl.h",
"src/objects/js-proxy.h",
"src/objects/js-raw-json-inl.h",
"src/objects/js-raw-json.h",
"src/objects/js-regexp-inl.h",
"src/objects/js-regexp-string-iterator-inl.h",
"src/objects/js-regexp-string-iterator.h",
"src/objects/js-regexp.h",
"src/objects/js-segments-inl.h",
"src/objects/js-segments.h",
"src/objects/js-shadow-realm-inl.h",
"src/objects/js-shadow-realm.h",
"src/objects/js-shared-array-inl.h",
"src/objects/js-shared-array.h",
Reland "[shared-struct] Prototype JS shared structs" This is a reland of 1025bf26e325bc1e746637a6e53ba8ab2e716ff1 Changes since revert: - TSAN issue fixed by https://crrev.com/c/3475084 - Skip the shared-struct-workers test until shared GC deadlock is fixed, being tracked in v8:12645 Original change's description: > [shared-struct] Prototype JS shared structs > > Unlike the Stage 1 proposal, for simplicity the prototype does not add > any new syntax, instead opting for exposing a SharedStructType > constructor which takes an array of field names. This type constructor > returns constructors for shared structs. > > Shared structs can be shared across Isolates, are fixed layout, have no > prototype, have no .constructor, and can only store primitives and > other shared structs. > > The initial prototype does not have TurboFan support. > > Bug: v8:12547 > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79156} Bug: v8:12547 Change-Id: Ic1f5cf9fa9791ae2d5d5dc7c110614ca10b5d98e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475078 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#79215}
2022-02-23 00:36:17 +00:00
"src/objects/js-struct-inl.h",
"src/objects/js-struct.h",
Reland "[Temporal] Part 1 - Skeleton" This is a reland of 0adc1410b1dae42b135b613ed86c18edafc83e3a 1. Fork out test/mjsunit/temporal/function-exist.js test to test/mjsunit/temporal/function-exist-no-i18n.js and mark function-exist FAIL in no_i18n build. Original change's description: > [Temporal] Part 1 - Skeleton > > 1. Expose all the functions to empty buildins. > 2. Wire up basic structure of classes and internal slots. > > Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/ > > This is just a CL to establish a skeleton for Temporal. > The Temporal is very big. The prototype CL is in > https://chromium-review.googlesource.com/c/v8/v8/+/2967755 > but too big to be reviewed so I break up the basic structure here first. > > Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel > Bug: v8:11544 > Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76819} Bug: v8:11544 Change-Id: I60eaface94ba9b3408cb235cd1ae425151a36732 Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324 Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77303}
2021-10-07 21:22:29 +00:00
"src/objects/js-temporal-objects-inl.h",
"src/objects/js-temporal-objects.h",
"src/objects/js-weak-refs-inl.h",
"src/objects/js-weak-refs.h",
"src/objects/keys.h",
"src/objects/literal-objects-inl.h",
"src/objects/literal-objects.h",
"src/objects/lookup-cache-inl.h",
"src/objects/lookup-cache.h",
"src/objects/lookup-inl.h",
"src/objects/lookup.h",
"src/objects/managed-inl.h",
"src/objects/managed.h",
"src/objects/map-inl.h",
"src/objects/map-updater.h",
"src/objects/map.h",
"src/objects/maybe-object-inl.h",
"src/objects/maybe-object.h",
Reland "[ic] Add a new MegaDOM IC" This is a reland of c83c9590baf677665b0872ca68cba2c1cf3524c1 Changes since revert: nothing, issue was crbug.com/v8/11666 Original change's description: > [ic] Add a new MegaDOM IC > > This patch implements the MegaDOM IC setup and access. A new MegaDOM > IC state indicates that we've seen only DOM accessors at this access > site. > > This CL only adds support for DOM getters in LoadIC, other kinds of > access will be added in follow on CLs. > > Still remaining TODO before shipping: > 1. Have a mechanism to invalidate the protector > 2. Have a mechanism to find the accessors that aren't overloaded > 3. Use a new builtin to miss to runtime on access check failure > > Change-Id: Ie12efe5e9fa284f023043b996d61e7d74e710ee2 > Bug: v8:11321 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2618239 > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Reviewed-by: Mythri Alle <mythria@chromium.org> > Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73733} Bug: v8:11321 Change-Id: I2bec54465542b5b40c42adb6eb12b6ce72cce5bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2794439 Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#74056}
2021-04-19 08:31:29 +00:00
"src/objects/megadom-handler-inl.h",
"src/objects/megadom-handler.h",
"src/objects/microtask-inl.h",
"src/objects/microtask.h",
"src/objects/module-inl.h",
"src/objects/module.h",
"src/objects/name-inl.h",
"src/objects/name.h",
"src/objects/object-list-macros.h",
"src/objects/object-macros-undef.h",
"src/objects/object-macros.h",
"src/objects/object-type.h",
"src/objects/objects-body-descriptors-inl.h",
"src/objects/objects-body-descriptors.h",
"src/objects/objects-definitions.h",
"src/objects/objects-inl.h",
"src/objects/objects.h",
"src/objects/oddball-inl.h",
"src/objects/oddball.h",
"src/objects/option-utils.h",
"src/objects/ordered-hash-table-inl.h",
"src/objects/ordered-hash-table.h",
[torque] Generate instance types Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
2019-10-11 21:52:06 +00:00
"src/objects/primitive-heap-object-inl.h",
"src/objects/primitive-heap-object.h",
"src/objects/promise-inl.h",
"src/objects/promise.h",
"src/objects/property-array-inl.h",
"src/objects/property-array.h",
"src/objects/property-cell-inl.h",
"src/objects/property-cell.h",
"src/objects/property-descriptor-object-inl.h",
"src/objects/property-descriptor-object.h",
"src/objects/property-descriptor.h",
"src/objects/property-details.h",
"src/objects/property.h",
"src/objects/prototype-info-inl.h",
"src/objects/prototype-info.h",
"src/objects/prototype-inl.h",
"src/objects/prototype.h",
"src/objects/regexp-match-info.h",
[torque] Begin porting ScopeInfo to Torque This change adds Torque field definitions for ScopeInfo and begins to use the Torque-generated accessors in some places. It does not change the in-memory layout of ScopeInfo. Torque compiler changes: - Fix an issue where the parser created constexpr types for classes based on the class name rather than the `generates` clause. This meant that generated accessors referred to the imaginary type HashTable rather than the real C++ type FixedArray. - Don't pass Isolate* through the generated runtime functions that implement Torque macros. Maybe we'll need it eventually, but we don't right now and it complicates a lot of things. - Don't emit `kSomeFieldOffset` if some_field has an unknown offset. Instead, emit a member function `SomeFieldOffset()` which fetches the slice for some_field and returns its offset. - Emit an `AllocatedSize()` member function for classes which have complex length expressions. It fetches the slice for the last field and performs the multiply&add to compute the total object size. - Emit field accessors for fields with complex length expressions, using the new offset functions. - Fix a few minor bugs where Torque can write uncompilable code. With this change, most code still treats ScopeInfo like a FixedArray, so I would like to follow up with some additional changes: 1. Generate a GC visitor for ScopeInfo and use it 2. Generate accessors for struct-typed fields (indexed or otherwise), and use them 3. Get rid of the FixedArray-style get and set accessors; use TaggedField::load and similar instead 4. Inherit from HeapObject rather than FixedArrayBase to remove the unnecessary `length` field After that, there will only be one ugly part left: initialization. I think it's possible to generate a factory function that takes a bunch of iterator parameters and returns a fully-formed, verifiably correct ScopeInfo instance, but doing so is more complicated than the four mostly-mechanical changes listed above. Bug: v8:7793 Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72187}
2021-01-19 18:20:26 +00:00
"src/objects/scope-info-inl.h",
"src/objects/scope-info.h",
"src/objects/script-inl.h",
"src/objects/script.h",
"src/objects/shared-function-info-inl.h",
"src/objects/shared-function-info.h",
"src/objects/simd.h",
"src/objects/slots-atomic-inl.h",
"src/objects/slots-inl.h",
"src/objects/slots.h",
"src/objects/smi-inl.h",
"src/objects/smi.h",
"src/objects/source-text-module-inl.h",
"src/objects/source-text-module.h",
"src/objects/string-comparator.h",
"src/objects/string-forwarding-table-inl.h",
"src/objects/string-forwarding-table.h",
"src/objects/string-inl.h",
[runtime] Move string table off-heap Changes the isolate's string table into an off-heap structure. This allows the string table to be resized without allocating on the V8 heap, and potentially triggering a GC. This allows existing strings to be inserted into the string table without requiring allocation. This has two important benefits: 1) It allows the deserializer to insert strings directly into the string table, rather than having to defer string insertion until deserialization completes. 2) It simplifies the concurrent string table lookup to allow resizing the table inside the write lock, therefore eliminating the race where two concurrent lookups could both resize the table. The off-heap string table has the following properties: 1) The general hashmap behaviour matches the HashTable, i.e. open addressing, power-of-two sized, quadratic probing. This could, of course, now be changed. 2) The empty and deleted sentinels are changed to Smi 0 and 1, respectively, to make those comparisons a bit cheaper and not require roots access. 3) When the HashTable is resized, the old elements array is kept alive in a linked list of previous arrays, so that concurrent lookups don't lose the data they're accessing. This linked list is cleared by the GC, as then we know that all threads are in a safepoint. 4) The GC treats the hash table entries as weak roots, and only walks them for non-live reference clearing and for evacuation. 5) Since there is no longer a FixedArray to serialize for the startup snapshot, there is now a custom serialization of the string table, and the string table root is considered unserializable during weak root iteration. As a bonus, the custom serialization is more efficient, as it skips non-string entries. As a drive-by, rename LookupStringExists_NoAllocate to TryStringToIndexOrLookupExisting, to make it clearer that it returns a non-string for the case when the string is an array index. As another drive-by, extract StringSet into a separate header. Bug: v8:10729 Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69270}
2020-08-06 10:59:55 +00:00
"src/objects/string-set-inl.h",
"src/objects/string-set.h",
"src/objects/string-table-inl.h",
"src/objects/string-table.h",
"src/objects/string.h",
"src/objects/struct-inl.h",
"src/objects/struct.h",
"src/objects/swiss-hash-table-helpers.h",
"src/objects/swiss-name-dictionary-inl.h",
"src/objects/swiss-name-dictionary.h",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/synthetic-module-inl.h",
"src/objects/synthetic-module.h",
"src/objects/tagged-field-inl.h",
"src/objects/tagged-field.h",
"src/objects/tagged-impl-inl.h",
"src/objects/tagged-impl.h",
"src/objects/tagged-index.h",
"src/objects/tagged-value-inl.h",
"src/objects/tagged-value.h",
"src/objects/template-objects-inl.h",
[es2015] Introduce dedicated GetTemplateObject bytecode. Tagged templates were previously desugared during parsing using some combination of runtime support written in JavaScript and C++, which prevented some optimizations from happening, namely the constant folding of the template object in TurboFan optimized code. This CL adds a new bytecode GetTemplateObject (with a corresponding GetTemplateObject AST node), which represents the abstract operation in the ES6 specification and allows TurboFan to simply constant-fold template objects at compile time (which is explicitly supported by the specification). This also pays down some technical debt by removing the template.js runtime support and therefore should reduce the size of the native context (snapshot) a bit. With this change in-place the ES6 version microbenchmark in the referenced tracking bug is now faster than the transpiled Babel code, it goes from templateStringTagES5: 4552 ms. templateStringTagES6: 14185 ms. templateStringTagBabel: 7626 ms. to templateStringTagES5: 4515 ms. templateStringTagES6: 7491 ms. templateStringTagBabel: 7639 ms. which corresponds to a solid 45% reduction in execution time. With some further optimizations the ES6 version should be able to outperform the ES5 version. This micro-benchmark should be fairly representative of the six-speed-templatestringtag-es6 benchmark, and as such that benchmark should also improve by around 50%. Bug: v8:6819,v8:6820 Tbr: mlippautz@chromium.org Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc Reviewed-on: https://chromium-review.googlesource.com/677462 Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48126}
2017-09-22 09:57:29 +00:00
"src/objects/template-objects.h",
"src/objects/templates-inl.h",
"src/objects/templates.h",
[torque] generate C++ class definitions per Torque file This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
2020-10-28 16:09:52 +00:00
"src/objects/torque-defined-classes-inl.h",
"src/objects/torque-defined-classes.h",
"src/objects/transitions-inl.h",
"src/objects/transitions.h",
Reland "[turbofan] extend type asserts to cover all JS types" This is a reland of 45227ffdb4319de48205a27cb5107342ac5a863e Differences: - Handle one more flags conflict in variants.py. - Disallow %VerifyType without --concurrent-recompilation. Original change's description: > [turbofan] extend type asserts to cover all JS types > > Extend type assertions to all types covering JavaScript values. > This is achieved by allocating type representations on the heap using > newly defined HeapObject subclasses. To allocate these in the compiler, > we disable concurrent compilation for the --assert-types flag for now. > > Fix two type errors that came up with the existing tests: > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of > OtherObject. > 2. OperationTyper::NumberToString(Type) can type the result as the > HeapConstant Factory::zero_string(). However, NumberToString does > not always produce this string. To avoid regressions, the CL keeps > the HeapConstant type and changes the runtime and builtin code to > always produce the canonical "0" string. > > A few tests were failing because they check for truncations to work > and prevent deoptimization. However, AssertType nodes destroy all > truncations (which is by design), so these tests are incompatible > and now disabled for the assert_types variant. > > Drive-by fix: a few minor Torque issues that came up. > > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77565} Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77596}
2021-10-27 20:38:52 +00:00
"src/objects/turbofan-types-inl.h",
"src/objects/turbofan-types.h",
"src/objects/turboshaft-types-inl.h",
"src/objects/turboshaft-types.h",
"src/objects/type-hints.h",
"src/objects/value-serializer.h",
"src/objects/visitors-inl.h",
"src/objects/visitors.h",
[parser] Replacing ExpressionClassifier with ExpressionScope that knows what it's tracking Since it's explicit what we're tracking, we can immediately throw errors in certain cases, and ignore irrelevant errors. We don't need to use the classifier itself to track "let let", since we know whether we're parsing a "let". Errors that were previously (almost) always accumulated are now immediately pushed to the scopes that care (parameter initialization errors). This CL drops avoiding allocation of classified errors, at least for now, but that doesn't affect performance anymore since we don't aggressively blacklist anymore. Classified errors are even less likely with the more precise approach. ParseAssignmentExpression doesn't introduce its own scope immediately, but reuses the outer scope. Rather than using full ExpressionClassifiers + Accumulate to separate expressions/patterns from each other while keeping track of the overall error state, this now uses an explicit AccumulationScope. When we parse (async) arrow functions we introduce new scopes that track that they may be (async) arrow functions. We track StrictModeFormal parameters in 2 different ways if it isn't immediately certain that it is a strict-mode formal error: Either directly on the (Pre)ParserFormalParameters, or on the NextArrowFunctionInfo in the case we're not yet certain that we'll have an arrow function. In the latter case we don't have a FormalParameter object yet, and we'll copy it over once we know we're parsing an arrow function. The latter works because it's not allowed to change strictness of a function with non-simple parameters. Design doc: https://docs.google.com/document/d/1FAvEp9EUK-G8kHfDIEo_385Hs2SUBCYbJ5H-NnLvq8M/ Change-Id: If4ecd717c9780095c7ddc859c8945b3d7d268a9d Reviewed-on: https://chromium-review.googlesource.com/c/1367809 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#58307}
2018-12-17 09:28:27 +00:00
"src/parsing/expression-scope.h",
"src/parsing/func-name-inferrer.h",
Sort import assertions by code point order of the keys Per https://tc39.es/proposal-import-assertions/#sec-assert-clause-to-assertions, import assertions should be sorted by the import assertion [[Key]]s, in order to prevent hosts from relying on a changing order of the assertions to determine behavior. Prior to this change, the assertions were being sorted by pointer. With this CL, the keys are sorted using a code point ordering so that the order of the assertions received by the host will be stable and non-surprising. This CL also switches the SourceTextModuleDescriptor's ModuleRequestMap, RegularExportMap, and RegularImportMap to use the code point order comparison rather than their former shortlex sort. This change will not be externally visible, but it seems best to make these consistent. In order to avoid #including the fairly large ast-value-factory.h into ast/modules.h, I changed ImportAssertions into a separate class definition rather than keeping it as a typedef. The alternative would be to define a common AstRawStringComparer in ast-value-factory.h and then #include ast-value-factory.h in both ast/modules.h and parsing/parser.h so that the ImportAssertions typedef would have a full, shared definition of the AstRawStringComparer type. Bug: v8:10958 Change-Id: I29c9544aa0a4340c56e1ee631be6cabb2a2eb921 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2533038 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71165}
2020-11-12 19:08:51 +00:00
"src/parsing/import-assertions.h",
"src/parsing/keywords-gen.h",
"src/parsing/literal-buffer.h",
"src/parsing/parse-info.h",
"src/parsing/parser-base.h",
"src/parsing/parser.h",
"src/parsing/parsing.h",
"src/parsing/pending-compilation-error-handler.h",
"src/parsing/preparse-data-impl.h",
"src/parsing/preparse-data.h",
"src/parsing/preparser-logger.h",
"src/parsing/preparser.h",
"src/parsing/rewriter.h",
"src/parsing/scanner-character-streams.h",
"src/parsing/scanner-inl.h",
"src/parsing/scanner.h",
"src/parsing/token.h",
"src/profiler/allocation-tracker.h",
"src/profiler/circular-queue-inl.h",
"src/profiler/circular-queue.h",
"src/profiler/cpu-profiler-inl.h",
"src/profiler/cpu-profiler.h",
"src/profiler/heap-profiler.h",
"src/profiler/heap-snapshot-generator-inl.h",
"src/profiler/heap-snapshot-generator.h",
"src/profiler/output-stream-writer.h",
"src/profiler/profile-generator-inl.h",
"src/profiler/profile-generator.h",
"src/profiler/profiler-listener.h",
"src/profiler/profiler-stats.h",
"src/profiler/sampling-heap-profiler.h",
"src/profiler/strings-storage.h",
"src/profiler/symbolizer.h",
"src/profiler/tick-sample.h",
"src/profiler/tracing-cpu-profiler.h",
"src/profiler/weak-code-registry.h",
"src/regexp/experimental/experimental-bytecode.h",
"src/regexp/experimental/experimental-compiler.h",
"src/regexp/experimental/experimental-interpreter.h",
"src/regexp/experimental/experimental.h",
"src/regexp/regexp-ast.h",
"src/regexp/regexp-bytecode-generator-inl.h",
"src/regexp/regexp-bytecode-generator.h",
"src/regexp/regexp-bytecode-peephole.h",
"src/regexp/regexp-bytecodes.h",
"src/regexp/regexp-compiler.h",
"src/regexp/regexp-dotprinter.h",
"src/regexp/regexp-error.h",
"src/regexp/regexp-flags.h",
"src/regexp/regexp-interpreter.h",
"src/regexp/regexp-macro-assembler-arch.h",
"src/regexp/regexp-macro-assembler-tracer.h",
"src/regexp/regexp-macro-assembler.h",
"src/regexp/regexp-nodes.h",
"src/regexp/regexp-parser.h",
"src/regexp/regexp-stack.h",
"src/regexp/regexp-utils.h",
"src/regexp/regexp.h",
"src/regexp/special-case.h",
"src/roots/roots-inl.h",
"src/roots/roots.h",
"src/roots/static-roots.h",
"src/runtime/runtime-utils.h",
"src/runtime/runtime.h",
"src/sandbox/bounded-size-inl.h",
"src/sandbox/bounded-size.h",
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
"src/sandbox/external-pointer-inl.h",
[sandbox] Implement GC for the external pointer table The external pointer table is now managed by the GC, which marks entries that are alive during major GC, then sweeps the table afterwards to free all dead entries and build a free list from them. For now, only major GCs are supported, Scavenger GCs do not interact with the external pointer table. In more detail, garbage collection of the external pointer table works as follows: 1. The external pointer table now reserves a large region of virtual address space for its backing buffer and is then never reallocated, only grown in place until the maximum size is reached. 2. When the GC's marking visitor marks a HeapObject with an external pointer as alive, it also marks the corresponding external pointer table entry as alive. This can happen on a background thread. 3. For that, it uses the MSB of each entry in the table to indicate whether the entry has been marked or not. This works because the MSB is always cleared during the AND-based type check performed when accessing an external pointer. 4. After marking, the external pointer table is swept while the mutator is stopped. This builds an inline, singly-linked freelist of all newly-dead and previously-free entries. 5. When allocating an entry from the table, the first entry on the freelist is used. If the freelist is empty, the table grows, populating the freelist with the new entries. 6. Every newly-allocated entry is marked as alive, and every store to an existing entry also automatically marks that entry as alive (by also setting the MSB). This simplifies the design of the table GC with regards to concurrency (See ExternalPointerTable::Mark). Bug: v8:10391 Change-Id: I8877fdf5576af3761bde65298951bb09e601bd14 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3359625 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Maya Lekova <mslekova@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78708}
2022-01-20 16:01:41 +00:00
"src/sandbox/external-pointer-table-inl.h",
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
"src/sandbox/external-pointer-table.h",
"src/sandbox/external-pointer.h",
"src/sandbox/sandbox.h",
"src/sandbox/sandboxed-pointer-inl.h",
"src/sandbox/sandboxed-pointer.h",
"src/sandbox/testing.h",
"src/snapshot/code-serializer.h",
"src/snapshot/context-deserializer.h",
"src/snapshot/context-serializer.h",
"src/snapshot/deserializer.h",
"src/snapshot/embedded/embedded-data-inl.h",
"src/snapshot/embedded/embedded-data.h",
"src/snapshot/embedded/embedded-file-writer-interface.h",
"src/snapshot/object-deserializer.h",
"src/snapshot/read-only-deserializer.h",
"src/snapshot/read-only-serializer.h",
"src/snapshot/references.h",
"src/snapshot/roots-serializer.h",
"src/snapshot/serializer-deserializer.h",
"src/snapshot/serializer-inl.h",
"src/snapshot/serializer.h",
"src/snapshot/shared-heap-deserializer.h",
"src/snapshot/shared-heap-serializer.h",
"src/snapshot/snapshot-data.h",
"src/snapshot/snapshot-source-sink.h",
"src/snapshot/snapshot-utils.h",
"src/snapshot/snapshot.h",
"src/snapshot/startup-deserializer.h",
"src/snapshot/startup-serializer.h",
"src/strings/char-predicates-inl.h",
"src/strings/char-predicates.h",
"src/strings/string-builder-inl.h",
"src/strings/string-case.h",
"src/strings/string-hasher-inl.h",
"src/strings/string-hasher.h",
"src/strings/string-search.h",
"src/strings/string-stream.h",
"src/strings/unicode-decoder.h",
"src/strings/unicode-inl.h",
"src/strings/unicode.h",
"src/strings/uri.h",
"src/tasks/cancelable-task.h",
"src/tasks/operations-barrier.h",
"src/tasks/task-utils.h",
"src/temporal/temporal-parser.h",
"src/third_party/siphash/halfsiphash.h",
"src/third_party/utf8-decoder/utf8-decoder.h",
"src/torque/runtime-macro-shims.h",
"src/tracing/trace-event.h",
"src/tracing/traced-value.h",
"src/tracing/tracing-category-observer.h",
"src/utils/address-map.h",
"src/utils/allocation.h",
"src/utils/bit-vector.h",
"src/utils/boxed-float.h",
"src/utils/detachable-vector.h",
"src/utils/hex-format.h",
"src/utils/identity-map.h",
"src/utils/locked-queue-inl.h",
"src/utils/locked-queue.h",
"src/utils/memcopy.h",
"src/utils/ostreams.h",
"src/utils/scoped-list.h",
"src/utils/sha-256.h",
"src/utils/sparse-bit-vector.h",
"src/utils/utils-inl.h",
"src/utils/utils.h",
"src/utils/version.h",
"src/zone/accounting-allocator.h",
"src/zone/compressed-zone-ptr.h",
"src/zone/type-stats.h",
"src/zone/zone-allocator.h",
"src/zone/zone-chunk-list.h",
"src/zone/zone-compression.h",
"src/zone/zone-containers.h",
"src/zone/zone-handle-set.h",
"src/zone/zone-hashmap.h",
"src/zone/zone-list-inl.h",
"src/zone/zone-list.h",
"src/zone/zone-segment.h",
"src/zone/zone-type-traits.h",
"src/zone/zone-utils.h",
"src/zone/zone.h",
]
if (v8_enable_snapshot_compression) {
sources += [ "src/snapshot/snapshot-compression.h" ]
}
if (v8_use_perfetto) {
sources -= [ "//base/trace_event/common/trace_event_common.h" ]
}
if (v8_enable_maglev) {
sources += [
"src/maglev/maglev-assembler.h",
"src/maglev/maglev-basic-block.h",
"src/maglev/maglev-code-gen-state.h",
"src/maglev/maglev-code-generator.h",
"src/maglev/maglev-compilation-info.h",
"src/maglev/maglev-compilation-unit.h",
"src/maglev/maglev-compiler.h",
"src/maglev/maglev-concurrent-dispatcher.h",
"src/maglev/maglev-graph-builder.h",
"src/maglev/maglev-graph-labeller.h",
"src/maglev/maglev-graph-printer.h",
"src/maglev/maglev-graph-processor.h",
"src/maglev/maglev-graph-verifier.h",
"src/maglev/maglev-graph.h",
"src/maglev/maglev-interpreter-frame-state.h",
"src/maglev/maglev-ir-inl.h",
"src/maglev/maglev-ir.h",
"src/maglev/maglev-regalloc-data.h",
"src/maglev/maglev-regalloc.h",
"src/maglev/maglev-register-frame-array.h",
"src/maglev/maglev.h",
]
if (v8_current_cpu == "arm64") {
sources += [ "src/maglev/arm64/maglev-assembler-arm64-inl.h" ]
} else if (v8_current_cpu == "x64") {
sources += [ "src/maglev/x64/maglev-assembler-x64-inl.h" ]
}
}
if (v8_enable_webassembly) {
sources += [
"src/asmjs/asm-js.h",
"src/asmjs/asm-names.h",
"src/asmjs/asm-parser.h",
"src/asmjs/asm-scanner.h",
"src/asmjs/asm-types.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/compiler/int64-lowering.h",
"src/compiler/wasm-compiler-definitions.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/compiler/wasm-compiler.h",
"src/compiler/wasm-escape-analysis.h",
"src/compiler/wasm-gc-lowering.h",
"src/compiler/wasm-gc-operator-reducer.h",
"src/compiler/wasm-graph-assembler.h",
"src/compiler/wasm-inlining.h",
"src/compiler/wasm-loop-peeling.h",
"src/compiler/wasm-typer.h",
"src/debug/debug-wasm-objects-inl.h",
"src/debug/debug-wasm-objects.h",
"src/third_party/utf8-decoder/generalized-utf8-decoder.h",
"src/trap-handler/trap-handler-internal.h",
"src/trap-handler/trap-handler.h",
"src/wasm/assembler-buffer-cache.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/baseline/liftoff-assembler-defs.h",
"src/wasm/baseline/liftoff-assembler.h",
"src/wasm/baseline/liftoff-compiler.h",
"src/wasm/baseline/liftoff-register.h",
"src/wasm/canonical-types.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/code-space-access.h",
"src/wasm/compilation-environment.h",
"src/wasm/constant-expression-interface.h",
"src/wasm/constant-expression.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/decoder.h",
"src/wasm/function-body-decoder-impl.h",
"src/wasm/function-body-decoder.h",
"src/wasm/function-compiler.h",
"src/wasm/graph-builder-interface.h",
"src/wasm/jump-table-assembler.h",
"src/wasm/leb-helper.h",
"src/wasm/local-decl-encoder.h",
"src/wasm/memory-tracing.h",
"src/wasm/module-compiler.h",
"src/wasm/module-decoder-impl.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/module-decoder.h",
"src/wasm/module-instantiate.h",
"src/wasm/names-provider.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/object-access.h",
"src/wasm/pgo.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/simd-shuffle.h",
"src/wasm/stacks.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/streaming-decoder.h",
"src/wasm/string-builder-multiline.h",
"src/wasm/string-builder.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/struct-types.h",
"src/wasm/value-type.h",
"src/wasm/wasm-arguments.h",
"src/wasm/wasm-code-manager.h",
"src/wasm/wasm-debug.h",
"src/wasm/wasm-disassembler-impl.h",
"src/wasm/wasm-disassembler.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/wasm-engine.h",
"src/wasm/wasm-external-refs.h",
"src/wasm/wasm-feature-flags.h",
"src/wasm/wasm-features.h",
"src/wasm/wasm-import-wrapper-cache.h",
"src/wasm/wasm-init-expr.h",
"src/wasm/wasm-js.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/wasm-linkage.h",
"src/wasm/wasm-module-builder.h",
"src/wasm/wasm-module-sourcemap.h",
"src/wasm/wasm-module.h",
"src/wasm/wasm-objects-inl.h",
"src/wasm/wasm-objects.h",
"src/wasm/wasm-opcodes-inl.h",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/wasm-opcodes.h",
"src/wasm/wasm-result.h",
"src/wasm/wasm-serialization.h",
"src/wasm/wasm-subtyping.h",
"src/wasm/wasm-tier.h",
"src/wasm/wasm-value.h",
]
}
if (v8_enable_wasm_simd256_revec) {
sources += [ "src/compiler/linear-scheduler.h" ]
}
if (!v8_enable_third_party_heap) {
sources += filter_include(v8_third_party_heap_files, [ "*.h" ])
} else {
sources += [ "src/heap/third-party/heap-api.h" ]
}
if (v8_enable_i18n_support) {
sources += [
"src/objects/intl-objects.h",
"src/objects/js-break-iterator-inl.h",
"src/objects/js-break-iterator.h",
"src/objects/js-collator-inl.h",
"src/objects/js-collator.h",
"src/objects/js-date-time-format-inl.h",
"src/objects/js-date-time-format.h",
"src/objects/js-display-names-inl.h",
"src/objects/js-display-names.h",
"src/objects/js-duration-format-inl.h",
"src/objects/js-duration-format.h",
"src/objects/js-list-format-inl.h",
"src/objects/js-list-format.h",
"src/objects/js-locale-inl.h",
"src/objects/js-locale.h",
"src/objects/js-number-format-inl.h",
"src/objects/js-number-format.h",
"src/objects/js-plural-rules-inl.h",
"src/objects/js-plural-rules.h",
"src/objects/js-relative-time-format-inl.h",
"src/objects/js-relative-time-format.h",
"src/objects/js-segment-iterator-inl.h",
"src/objects/js-segment-iterator.h",
"src/objects/js-segmenter-inl.h",
"src/objects/js-segmenter.h",
"src/objects/js-segments-inl.h",
"src/objects/js-segments.h",
]
}
if (!v8_control_flow_integrity) {
sources += [ "src/execution/pointer-authentication-dummy.h" ]
}
if (v8_enable_conservative_stack_scanning) {
sources += [ "src/heap/conservative-stack-visitor.h" ]
}
if (v8_enable_inner_pointer_resolution_osb) {
sources += [
"src/heap/object-start-bitmap-inl.h",
"src/heap/object-start-bitmap.h",
]
}
if (v8_enable_wasm_gdb_remote_debugging) {
sources += [
"src/debug/wasm/gdb-server/gdb-remote-util.h",
"src/debug/wasm/gdb-server/gdb-server-thread.h",
"src/debug/wasm/gdb-server/gdb-server.h",
"src/debug/wasm/gdb-server/packet.h",
"src/debug/wasm/gdb-server/session.h",
"src/debug/wasm/gdb-server/target.h",
"src/debug/wasm/gdb-server/transport.h",
"src/debug/wasm/gdb-server/wasm-module-debug.h",
]
}
if (v8_enable_heap_snapshot_verify) {
sources += [ "src/heap/reference-summarizer.h" ]
}
if (v8_current_cpu == "x86") {
sources += [
### gcmole(ia32) ###
"src/baseline/ia32/baseline-assembler-ia32-inl.h",
"src/baseline/ia32/baseline-compiler-ia32-inl.h",
"src/codegen/ia32/assembler-ia32-inl.h",
"src/codegen/ia32/assembler-ia32.h",
"src/codegen/ia32/constants-ia32.h",
"src/codegen/ia32/interface-descriptors-ia32-inl.h",
"src/codegen/ia32/macro-assembler-ia32.h",
"src/codegen/ia32/register-ia32.h",
"src/codegen/ia32/reglist-ia32.h",
"src/codegen/ia32/sse-instr.h",
"src/codegen/shared-ia32-x64/macro-assembler-shared-ia32-x64.h",
"src/compiler/backend/ia32/instruction-codes-ia32.h",
"src/execution/ia32/frame-constants-ia32.h",
"src/regexp/ia32/regexp-macro-assembler-ia32.h",
"src/wasm/baseline/ia32/liftoff-assembler-ia32.h",
]
} else if (v8_current_cpu == "x64") {
sources += [
### gcmole(x64) ###
"src/baseline/x64/baseline-assembler-x64-inl.h",
"src/baseline/x64/baseline-compiler-x64-inl.h",
"src/codegen/shared-ia32-x64/macro-assembler-shared-ia32-x64.h",
"src/codegen/x64/assembler-x64-inl.h",
"src/codegen/x64/assembler-x64.h",
"src/codegen/x64/constants-x64.h",
"src/codegen/x64/fma-instr.h",
"src/codegen/x64/interface-descriptors-x64-inl.h",
"src/codegen/x64/macro-assembler-x64.h",
"src/codegen/x64/register-x64.h",
"src/codegen/x64/reglist-x64.h",
"src/codegen/x64/sse-instr.h",
"src/compiler/backend/x64/instruction-codes-x64.h",
"src/compiler/backend/x64/unwinding-info-writer-x64.h",
"src/execution/x64/frame-constants-x64.h",
"src/regexp/x64/regexp-macro-assembler-x64.h",
"src/third_party/valgrind/valgrind.h",
"src/wasm/baseline/x64/liftoff-assembler-x64.h",
]
2021-06-11 18:05:23 +00:00
if (is_win) {
sources += [ "src/diagnostics/unwinding-info-win64.h" ]
}
if (v8_enable_webassembly) {
# iOS Xcode simulator builds run on an x64 target. iOS and macOS are both
# based on Darwin and thus POSIX-compliant to a similar degree.
if (is_linux || is_chromeos || is_mac || is_ios ||
target_os == "freebsd") {
sources += [ "src/trap-handler/handler-inside-posix.h" ]
} else if (is_win) {
sources += [ "src/trap-handler/handler-inside-win.h" ]
}
}
} else if (v8_current_cpu == "arm") {
sources += [
### gcmole(arm) ###
"src/baseline/arm/baseline-assembler-arm-inl.h",
"src/baseline/arm/baseline-compiler-arm-inl.h",
"src/codegen/arm/assembler-arm-inl.h",
"src/codegen/arm/assembler-arm.h",
"src/codegen/arm/constants-arm.h",
"src/codegen/arm/interface-descriptors-arm-inl.h",
"src/codegen/arm/macro-assembler-arm.h",
"src/codegen/arm/register-arm.h",
"src/codegen/arm/reglist-arm.h",
"src/compiler/backend/arm/instruction-codes-arm.h",
"src/compiler/backend/arm/unwinding-info-writer-arm.h",
"src/execution/arm/frame-constants-arm.h",
"src/execution/arm/simulator-arm.h",
"src/regexp/arm/regexp-macro-assembler-arm.h",
"src/wasm/baseline/arm/liftoff-assembler-arm.h",
]
} else if (v8_current_cpu == "arm64") {
sources += [
### gcmole(arm64) ###
"src/baseline/arm64/baseline-assembler-arm64-inl.h",
"src/baseline/arm64/baseline-compiler-arm64-inl.h",
"src/codegen/arm64/assembler-arm64-inl.h",
"src/codegen/arm64/assembler-arm64.h",
"src/codegen/arm64/constants-arm64.h",
"src/codegen/arm64/decoder-arm64-inl.h",
"src/codegen/arm64/decoder-arm64.h",
"src/codegen/arm64/instructions-arm64.h",
"src/codegen/arm64/interface-descriptors-arm64-inl.h",
"src/codegen/arm64/macro-assembler-arm64-inl.h",
"src/codegen/arm64/macro-assembler-arm64.h",
"src/codegen/arm64/register-arm64.h",
"src/codegen/arm64/reglist-arm64.h",
"src/codegen/arm64/utils-arm64.h",
"src/compiler/backend/arm64/instruction-codes-arm64.h",
"src/compiler/backend/arm64/unwinding-info-writer-arm64.h",
"src/diagnostics/arm64/disasm-arm64.h",
"src/execution/arm64/frame-constants-arm64.h",
"src/execution/arm64/simulator-arm64.h",
"src/regexp/arm64/regexp-macro-assembler-arm64.h",
"src/wasm/baseline/arm64/liftoff-assembler-arm64.h",
]
if (v8_control_flow_integrity) {
sources += [ "src/execution/arm64/pointer-authentication-arm64.h" ]
}
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
if (v8_enable_webassembly) {
# Trap handling is enabled on arm64 Mac and in simulators on x64 on Linux
# and Mac.
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
if ((current_cpu == "arm64" && is_mac) ||
(current_cpu == "x64" && (is_linux || is_chromeos || is_mac))) {
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
sources += [ "src/trap-handler/handler-inside-posix.h" ]
}
if (current_cpu == "x64" &&
(is_linux || is_chromeos || is_mac || is_win)) {
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
sources += [ "src/trap-handler/trap-handler-simulator.h" ]
}
}
if (is_win) {
sources += [ "src/diagnostics/unwinding-info-win64.h" ]
}
} else if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
sources += [
### gcmole(mips64el) ###
"src/baseline/mips64/baseline-assembler-mips64-inl.h",
"src/baseline/mips64/baseline-compiler-mips64-inl.h",
"src/codegen/mips64/assembler-mips64-inl.h",
"src/codegen/mips64/assembler-mips64.h",
"src/codegen/mips64/constants-mips64.h",
"src/codegen/mips64/macro-assembler-mips64.h",
"src/codegen/mips64/register-mips64.h",
"src/codegen/mips64/reglist-mips64.h",
"src/compiler/backend/mips64/instruction-codes-mips64.h",
"src/execution/mips64/frame-constants-mips64.h",
"src/execution/mips64/simulator-mips64.h",
"src/regexp/mips64/regexp-macro-assembler-mips64.h",
"src/wasm/baseline/mips64/liftoff-assembler-mips64.h",
]
} else if (v8_current_cpu == "loong64") {
sources += [
### gcmole(loong64) ###
"src/baseline/loong64/baseline-assembler-loong64-inl.h",
"src/baseline/loong64/baseline-compiler-loong64-inl.h",
"src/codegen/loong64/assembler-loong64-inl.h",
"src/codegen/loong64/assembler-loong64.h",
"src/codegen/loong64/constants-loong64.h",
"src/codegen/loong64/macro-assembler-loong64.h",
"src/codegen/loong64/register-loong64.h",
"src/codegen/loong64/reglist-loong64.h",
"src/compiler/backend/loong64/instruction-codes-loong64.h",
"src/execution/loong64/frame-constants-loong64.h",
"src/execution/loong64/simulator-loong64.h",
"src/regexp/loong64/regexp-macro-assembler-loong64.h",
"src/wasm/baseline/loong64/liftoff-assembler-loong64.h",
]
} else if (v8_current_cpu == "ppc") {
sources += [
### gcmole(ppc) ###
"src/codegen/ppc/assembler-ppc-inl.h",
"src/codegen/ppc/assembler-ppc.h",
"src/codegen/ppc/constants-ppc.h",
"src/codegen/ppc/interface-descriptors-ppc-inl.h",
"src/codegen/ppc/macro-assembler-ppc.h",
"src/codegen/ppc/register-ppc.h",
"src/codegen/ppc/reglist-ppc.h",
"src/compiler/backend/ppc/instruction-codes-ppc.h",
"src/compiler/backend/ppc/unwinding-info-writer-ppc.h",
"src/execution/ppc/frame-constants-ppc.h",
"src/execution/ppc/simulator-ppc.h",
"src/regexp/ppc/regexp-macro-assembler-ppc.h",
"src/wasm/baseline/ppc/liftoff-assembler-ppc.h",
]
} else if (v8_current_cpu == "ppc64") {
sources += [
### gcmole(ppc64) ###
"src/baseline/ppc/baseline-assembler-ppc-inl.h",
"src/baseline/ppc/baseline-compiler-ppc-inl.h",
"src/codegen/ppc/assembler-ppc-inl.h",
"src/codegen/ppc/assembler-ppc.h",
"src/codegen/ppc/constants-ppc.h",
"src/codegen/ppc/interface-descriptors-ppc-inl.h",
"src/codegen/ppc/macro-assembler-ppc.h",
"src/codegen/ppc/register-ppc.h",
"src/codegen/ppc/reglist-ppc.h",
"src/compiler/backend/ppc/instruction-codes-ppc.h",
"src/compiler/backend/ppc/unwinding-info-writer-ppc.h",
"src/execution/ppc/frame-constants-ppc.h",
"src/execution/ppc/simulator-ppc.h",
"src/regexp/ppc/regexp-macro-assembler-ppc.h",
"src/wasm/baseline/ppc/liftoff-assembler-ppc.h",
]
} else if (v8_current_cpu == "s390" || v8_current_cpu == "s390x") {
sources += [
### gcmole(s390) ###
"src/baseline/s390/baseline-assembler-s390-inl.h",
"src/baseline/s390/baseline-compiler-s390-inl.h",
"src/codegen/s390/assembler-s390-inl.h",
"src/codegen/s390/assembler-s390.h",
"src/codegen/s390/constants-s390.h",
"src/codegen/s390/interface-descriptors-s390-inl.h",
"src/codegen/s390/macro-assembler-s390.h",
"src/codegen/s390/register-s390.h",
"src/codegen/s390/reglist-s390.h",
"src/compiler/backend/s390/instruction-codes-s390.h",
"src/compiler/backend/s390/unwinding-info-writer-s390.h",
"src/execution/s390/frame-constants-s390.h",
"src/execution/s390/simulator-s390.h",
"src/regexp/s390/regexp-macro-assembler-s390.h",
"src/wasm/baseline/s390/liftoff-assembler-s390.h",
]
} else if (v8_current_cpu == "riscv64") {
sources += [
### gcmole(riscv64) ###
"src/baseline/riscv/baseline-assembler-riscv-inl.h",
"src/baseline/riscv/baseline-compiler-riscv-inl.h",
"src/codegen/riscv/assembler-riscv-inl.h",
"src/codegen/riscv/assembler-riscv-inl.h",
"src/codegen/riscv/assembler-riscv.h",
"src/codegen/riscv/base-assembler-riscv.h",
"src/codegen/riscv/base-constants-riscv.h",
"src/codegen/riscv/base-riscv-i.h",
"src/codegen/riscv/base-riscv-i.h",
"src/codegen/riscv/constant-riscv-a.h",
"src/codegen/riscv/constant-riscv-c.h",
"src/codegen/riscv/constant-riscv-d.h",
"src/codegen/riscv/constant-riscv-f.h",
"src/codegen/riscv/constant-riscv-m.h",
"src/codegen/riscv/constant-riscv-v.h",
"src/codegen/riscv/constant-riscv-zicsr.h",
"src/codegen/riscv/constant-riscv-zifencei.h",
"src/codegen/riscv/constants-riscv.h",
"src/codegen/riscv/extension-riscv-a.h",
"src/codegen/riscv/extension-riscv-c.h",
"src/codegen/riscv/extension-riscv-d.h",
"src/codegen/riscv/extension-riscv-d.h",
"src/codegen/riscv/extension-riscv-inl.h",
"src/codegen/riscv/extension-riscv-m.h",
"src/codegen/riscv/extension-riscv-v.h",
"src/codegen/riscv/extension-riscv-zicsr.h",
"src/codegen/riscv/extension-riscv-zifencei.h",
"src/codegen/riscv/interface-descriptors-riscv-inl.h",
"src/codegen/riscv/macro-assembler-riscv.h",
"src/codegen/riscv/register-riscv.h",
"src/codegen/riscv/reglist-riscv.h",
"src/compiler/backend/riscv/instruction-codes-riscv.h",
"src/execution/riscv/frame-constants-riscv.h",
"src/execution/riscv/simulator-riscv.h",
"src/regexp/riscv/regexp-macro-assembler-riscv.h",
"src/wasm/baseline/riscv64/liftoff-assembler-riscv64.h",
]
} else if (v8_current_cpu == "riscv32") {
sources += [
### gcmole(riscv32) ###
"src/baseline/riscv/baseline-assembler-riscv-inl.h",
"src/baseline/riscv/baseline-compiler-riscv-inl.h",
"src/codegen/riscv/assembler-riscv.h",
"src/codegen/riscv/assembler-riscv32-inl.h",
"src/codegen/riscv/base-assembler-riscv.h",
"src/codegen/riscv/base-constants-riscv.h",
"src/codegen/riscv/base-riscv-i.h",
"src/codegen/riscv/constant-riscv-a.h",
"src/codegen/riscv/constant-riscv-c.h",
"src/codegen/riscv/constant-riscv-d.h",
"src/codegen/riscv/constant-riscv-f.h",
"src/codegen/riscv/constant-riscv-i.h",
"src/codegen/riscv/constant-riscv-m.h",
"src/codegen/riscv/constant-riscv-v.h",
"src/codegen/riscv/constant-riscv-zicsr.h",
"src/codegen/riscv/constant-riscv-zifencei.h",
"src/codegen/riscv/constants-riscv.h",
"src/codegen/riscv/extension-riscv-a.h",
"src/codegen/riscv/extension-riscv-c.h",
"src/codegen/riscv/extension-riscv-d.h",
"src/codegen/riscv/extension-riscv-f.h",
"src/codegen/riscv/extension-riscv-inl.h",
"src/codegen/riscv/extension-riscv-m.h",
"src/codegen/riscv/extension-riscv-v.h",
"src/codegen/riscv/extension-riscv-zicsr.h",
"src/codegen/riscv/extension-riscv-zifencei.h",
"src/codegen/riscv/interface-descriptors-riscv-inl.h",
"src/codegen/riscv/macro-assembler-riscv.h",
"src/codegen/riscv/register-riscv.h",
"src/codegen/riscv/reglist-riscv.h",
"src/compiler/backend/riscv/instruction-codes-riscv.h",
"src/execution/riscv/frame-constants-riscv.h",
"src/execution/riscv/simulator-riscv.h",
"src/regexp/riscv/regexp-macro-assembler-riscv.h",
"src/wasm/baseline/riscv32/liftoff-assembler-riscv32.h",
]
}
public_deps = [
":torque_runtime_support",
":v8_flags",
":v8_headers",
":v8_maybe_icu",
":v8_shared_internal_headers",
]
deps = [
":cppgc_headers",
":generate_bytecode_builtins_list",
":run_torque",
[heap] Improve accounting of PagedSpace::CommittedPhysicalMemory() Instead of using the high water mark for determining this metric, we use a bitset for all active/used system pages on a V8 heap page. Each time when allocating a LAB on a page, we add the pages of that memory range to that bitset. During sweeping we rebuild that bitset from scratch and replace it with the old one in case free pages are discarded by the GC. We DCHECK here that the sweeper only ever removes pages. This has the nice benefit of ensuring that we don't miss any allocations (like we do now for concurrent allocations). CommittedPhysicalMemory for a page is then calculated by counting the set bits in the bitset and multiplying it with the system page size. This should be simpler to verify and track the "real" effective size more precisely. One case where we are partially less precise than the current implementation is for LABs. In order to reduce complexity we now treat all pages of a LAB allocation as active immediately. In the current implementation we tried to only account the actual used part of the LAB when changing the LAB later. This is more complex to track correctly but also doesn't account the currently used LAB in effective size. Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#79428}
2022-03-09 16:49:56 +00:00
":v8_heap_base_headers",
":v8_libbase",
]
}
v8_compiler_sources = [
### gcmole(all) ###
"src/compiler/access-builder.cc",
"src/compiler/access-info.cc",
"src/compiler/add-type-assertions-reducer.cc",
"src/compiler/all-nodes.cc",
"src/compiler/backend/bitcast-elider.cc",
"src/compiler/backend/code-generator.cc",
"src/compiler/backend/frame-elider.cc",
"src/compiler/backend/gap-resolver.cc",
"src/compiler/backend/instruction-scheduler.cc",
"src/compiler/backend/instruction-selector.cc",
"src/compiler/backend/instruction.cc",
"src/compiler/backend/jump-threading.cc",
"src/compiler/backend/mid-tier-register-allocator.cc",
"src/compiler/backend/move-optimizer.cc",
"src/compiler/backend/register-allocator-verifier.cc",
"src/compiler/backend/register-allocator.cc",
"src/compiler/backend/spill-placer.cc",
"src/compiler/basic-block-instrumentor.cc",
Reland^2 [compiler] Simplify "==0" branches in MachineOperatorReducer This is a reland of 6b690a6b48e418d474bfda4cc536fde087e61515. The previous version of this CL was a bit too aggressive in the duplication of branch conditions. This caused an increase in register pressure in some cases, thus reducing performance. In fact, duplicating branch conditions that require an "== 0" to be added provides no benefits. We are thus now a bit less aggressive, and only duplicate comparisons. Original change's description: > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer > > This is a reland of 48b443f69291a4b0dde9db36aae11c29c3c0cb2d. > > While fixing the initial CL, we stumbled upon a few bugs that > we had to fix: > > - CommonOperatorReducer and SimplifiedOperatorReducer were applied > before and after SimplifiedLowering, but always assumed that it > was before SimplifiedLowering, and thus had the wrong semantics > for branches in some cases. They now have an added parameter to > know which semantics of branch they should use. > > - The lowering of StaticAssert was wrong and could leave kHeapConstant > in the assert (instead of machine Booleans). > > Original change's description: > > [compiler] Simplify "==0" branches in MachineOperatorReducer > > > > Bug: v8:12484 > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Owners-Override: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#79379} > > Bug: v8:12484 > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Darius Mercadier <dmercadier@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79528} Bug: v8:12484 Change-Id: I31f575a59811a83c7c1acb4c14bf5ded63a8f536 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540102 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Cr-Commit-Position: refs/heads/main@{#79560}
2022-03-21 16:55:30 +00:00
"src/compiler/branch-condition-duplicator.cc",
"src/compiler/branch-elimination.cc",
"src/compiler/bytecode-analysis.cc",
"src/compiler/bytecode-graph-builder.cc",
"src/compiler/bytecode-liveness-map.cc",
"src/compiler/c-linkage.cc",
"src/compiler/checkpoint-elimination.cc",
"src/compiler/code-assembler.cc",
"src/compiler/common-node-cache.cc",
"src/compiler/common-operator-reducer.cc",
"src/compiler/common-operator.cc",
"src/compiler/compilation-dependencies.cc",
"src/compiler/compiler-source-position-table.cc",
"src/compiler/constant-folding-reducer.cc",
"src/compiler/control-equivalence.cc",
"src/compiler/control-flow-optimizer.cc",
"src/compiler/csa-load-elimination.cc",
"src/compiler/dead-code-elimination.cc",
"src/compiler/decompression-optimizer.cc",
"src/compiler/effect-control-linearizer.cc",
"src/compiler/escape-analysis-reducer.cc",
"src/compiler/escape-analysis.cc",
"src/compiler/fast-api-calls.cc",
"src/compiler/feedback-source.cc",
"src/compiler/frame-states.cc",
"src/compiler/frame.cc",
"src/compiler/graph-assembler.cc",
"src/compiler/graph-reducer.cc",
"src/compiler/graph-trimmer.cc",
"src/compiler/graph-visualizer.cc",
"src/compiler/graph.cc",
"src/compiler/heap-refs.cc",
"src/compiler/js-call-reducer.cc",
"src/compiler/js-context-specialization.cc",
"src/compiler/js-create-lowering.cc",
"src/compiler/js-generic-lowering.cc",
"src/compiler/js-graph.cc",
"src/compiler/js-heap-broker.cc",
"src/compiler/js-inlining-heuristic.cc",
"src/compiler/js-inlining.cc",
"src/compiler/js-intrinsic-lowering.cc",
"src/compiler/js-native-context-specialization.cc",
"src/compiler/js-operator.cc",
"src/compiler/js-type-hint-lowering.cc",
"src/compiler/js-typed-lowering.cc",
"src/compiler/late-escape-analysis.cc",
"src/compiler/linkage.cc",
"src/compiler/load-elimination.cc",
"src/compiler/loop-analysis.cc",
"src/compiler/loop-peeling.cc",
"src/compiler/loop-unrolling.cc",
"src/compiler/loop-variable-optimizer.cc",
"src/compiler/machine-graph-verifier.cc",
"src/compiler/machine-graph.cc",
"src/compiler/machine-operator-reducer.cc",
"src/compiler/machine-operator.cc",
"src/compiler/map-inference.cc",
"src/compiler/memory-lowering.cc",
"src/compiler/memory-optimizer.cc",
"src/compiler/node-marker.cc",
"src/compiler/node-matchers.cc",
"src/compiler/node-observer.cc",
"src/compiler/node-origin-table.cc",
"src/compiler/node-properties.cc",
"src/compiler/node.cc",
"src/compiler/opcodes.cc",
"src/compiler/operation-typer.cc",
"src/compiler/operator-properties.cc",
"src/compiler/operator.cc",
"src/compiler/osr.cc",
"src/compiler/pipeline-statistics.cc",
"src/compiler/pipeline.cc",
"src/compiler/property-access-builder.cc",
"src/compiler/raw-machine-assembler.cc",
"src/compiler/redundancy-elimination.cc",
"src/compiler/refs-map.cc",
"src/compiler/representation-change.cc",
"src/compiler/schedule.cc",
"src/compiler/scheduler.cc",
"src/compiler/select-lowering.cc",
"src/compiler/simplified-lowering-verifier.cc",
"src/compiler/simplified-lowering.cc",
"src/compiler/simplified-operator-reducer.cc",
"src/compiler/simplified-operator.cc",
"src/compiler/state-values-utils.cc",
"src/compiler/store-store-elimination.cc",
"src/compiler/type-cache.cc",
"src/compiler/type-narrowing-reducer.cc",
"src/compiler/typed-optimization.cc",
"src/compiler/typer.cc",
"src/compiler/types.cc",
"src/compiler/value-numbering-reducer.cc",
"src/compiler/verifier.cc",
"src/compiler/zone-stats.cc",
"src/utils/hex-format.cc",
"src/utils/sha-256.cc",
]
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
if (v8_enable_webassembly) {
v8_compiler_sources += [
"src/compiler/int64-lowering.cc",
"src/compiler/wasm-compiler.cc",
"src/compiler/wasm-escape-analysis.cc",
"src/compiler/wasm-gc-lowering.cc",
"src/compiler/wasm-gc-operator-reducer.cc",
"src/compiler/wasm-graph-assembler.cc",
"src/compiler/wasm-inlining.cc",
"src/compiler/wasm-loop-peeling.cc",
"src/compiler/wasm-typer.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
]
}
if (v8_enable_wasm_simd256_revec) {
v8_compiler_sources += [ "src/compiler/linear-scheduler.cc" ]
}
# The src/compiler files with optimizations.
v8_source_set("v8_compiler_opt") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = v8_compiler_sources
public_deps = [
":generate_bytecode_builtins_list",
":run_torque",
":v8_maybe_icu",
":v8_tracing",
]
deps = [
":v8_base_without_compiler",
":v8_internal_headers",
":v8_libbase",
":v8_shared_internal_headers",
]
if (is_debug && !v8_optimized_debug && v8_enable_fast_mksnapshot) {
# The :no_optimize config is added to v8_add_configs in v8.gni.
remove_configs = [ "//build/config/compiler:no_optimize" ]
configs = [ ":always_turbofanimize" ]
} else {
# Without this else branch, gn fails to generate build files for non-debug
# builds (because we try to remove a config that is not present).
# So we include it, even if this config is not used outside of debug builds.
configs = [ ":internal_config" ]
}
}
# The src/compiler files with default optimization behavior.
v8_source_set("v8_compiler") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = v8_compiler_sources
public_deps = [
":generate_bytecode_builtins_list",
":run_torque",
":v8_internal_headers",
":v8_maybe_icu",
":v8_tracing",
]
deps = [
":v8_base_without_compiler",
":v8_libbase",
":v8_shared_internal_headers",
]
configs = [ ":internal_config" ]
}
# The src/compiler files with default optimization behavior.
v8_source_set("v8_turboshaft") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [
"src/compiler/turboshaft/assembler.cc",
"src/compiler/turboshaft/decompression-optimization.cc",
"src/compiler/turboshaft/graph-builder.cc",
"src/compiler/turboshaft/graph-visualizer.cc",
"src/compiler/turboshaft/graph.cc",
"src/compiler/turboshaft/late-escape-analysis-reducer.cc",
"src/compiler/turboshaft/memory-optimization.cc",
"src/compiler/turboshaft/operations.cc",
"src/compiler/turboshaft/optimization-phase.cc",
"src/compiler/turboshaft/recreate-schedule.cc",
"src/compiler/turboshaft/representations.cc",
"src/compiler/turboshaft/simplify-tf-loops.cc",
"src/compiler/turboshaft/types.cc",
"src/compiler/turboshaft/utils.cc",
]
public_deps = [
":generate_bytecode_builtins_list",
":run_torque",
":v8_internal_headers",
":v8_maybe_icu",
":v8_tracing",
]
deps = [
":v8_base_without_compiler",
":v8_libbase",
":v8_shared_internal_headers",
]
configs = [ ":internal_config" ]
}
group("v8_compiler_for_mksnapshot") {
if (is_debug && !v8_optimized_debug && v8_enable_fast_mksnapshot) {
deps = [ ":v8_compiler_opt" ]
} else {
deps = [ ":v8_compiler" ]
}
}
# Any target using trace events must directly or indirectly depend on
# v8_tracing.
group("v8_tracing") {
if (v8_use_perfetto) {
if (build_with_chromium) {
public_deps = [ "//third_party/perfetto:libperfetto" ]
} else {
public_deps = [ ":v8_libperfetto" ]
}
}
}
v8_source_set("v8_base_without_compiler") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
# Split static libraries on windows into two.
split_count = 2
sources = [
### gcmole(all) ###
"src/api/api-arguments.cc",
"src/api/api-natives.cc",
"src/api/api.cc",
"src/ast/ast-function-literal-id-reindexer.cc",
"src/ast/ast-value-factory.cc",
"src/ast/ast.cc",
"src/ast/modules.cc",
"src/ast/prettyprinter.cc",
"src/ast/scopes.cc",
"src/ast/source-range-ast-visitor.cc",
"src/ast/variables.cc",
"src/baseline/baseline-batch-compiler.cc",
"src/baseline/baseline-compiler.cc",
"src/baseline/baseline.cc",
Reland "[sparkplug] Change bytecode offset mapping and introduce iterator." This is a reland of a8b61ef521c51e0d1d84ed744e893273ed5d516c The main reason for the revert was not related to this CL and was fixed with https://crrev.com/c/2739646 In addition debug output in d8.test.verifySourcePositions was removed due to TSAN complaints. Original change's description: > [sparkplug] Change bytecode offset mapping and introduce iterator. > > Previously, we recorded pairs of (bytecode offset, sparkplug pc) to > create a mapping of bytecode offset <-> sparkplug pc. > These pairs were only recorded after builtin/runtime calls. > In preparation for deoptimizing to Sparkplug, we need a more precise > mapping. > With this CL, we record positions for every bytecode. Instead of storing > a pair of (bytecode offset, sparkplug pc), we store only the pc, > calculating the bytecode offset from the index in the mapping table. > For easier use an iterator to access the mapping is introduced. > > Drive-by: Reduce sampling interval in cpu-profiler cctest to get rid of flaky failures. > > Bug: v8:11420, v8:11429 > Change-Id: I36a9171f43a574eb67880cbca6cf9ff7ab291e60 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2720189 > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Auto-Submit: Patrick Thier <pthier@chromium.org> > Commit-Queue: Patrick Thier <pthier@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73186} > > Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6 Change-Id: I9ab4cb60da002ef130f8a21ad10ba69e2826a7b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2745335 Reviewed-by: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/master@{#73293}
2021-03-09 11:18:52 +00:00
"src/baseline/bytecode-offset-iterator.cc",
"src/builtins/accessors.cc",
"src/builtins/builtins-api.cc",
"src/builtins/builtins-array.cc",
"src/builtins/builtins-arraybuffer.cc",
"src/builtins/builtins-async-module.cc",
"src/builtins/builtins-atomics-synchronization.cc",
"src/builtins/builtins-bigint.cc",
"src/builtins/builtins-callsite.cc",
"src/builtins/builtins-collections.cc",
"src/builtins/builtins-console.cc",
"src/builtins/builtins-dataview.cc",
"src/builtins/builtins-date.cc",
"src/builtins/builtins-error.cc",
"src/builtins/builtins-function.cc",
"src/builtins/builtins-global.cc",
"src/builtins/builtins-internal.cc",
"src/builtins/builtins-intl.cc",
"src/builtins/builtins-json.cc",
"src/builtins/builtins-number.cc",
"src/builtins/builtins-object.cc",
"src/builtins/builtins-reflect.cc",
"src/builtins/builtins-regexp.cc",
"src/builtins/builtins-shadow-realm.cc",
"src/builtins/builtins-shared-array.cc",
"src/builtins/builtins-sharedarraybuffer.cc",
"src/builtins/builtins-string.cc",
Reland "[shared-struct] Prototype JS shared structs" This is a reland of 1025bf26e325bc1e746637a6e53ba8ab2e716ff1 Changes since revert: - TSAN issue fixed by https://crrev.com/c/3475084 - Skip the shared-struct-workers test until shared GC deadlock is fixed, being tracked in v8:12645 Original change's description: > [shared-struct] Prototype JS shared structs > > Unlike the Stage 1 proposal, for simplicity the prototype does not add > any new syntax, instead opting for exposing a SharedStructType > constructor which takes an array of field names. This type constructor > returns constructors for shared structs. > > Shared structs can be shared across Isolates, are fixed layout, have no > prototype, have no .constructor, and can only store primitives and > other shared structs. > > The initial prototype does not have TurboFan support. > > Bug: v8:12547 > Change-Id: I23bdd819940b42139692bcdb53d372099b0d4426 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3390643 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Marja Hölttä <marja@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79156} Bug: v8:12547 Change-Id: Ic1f5cf9fa9791ae2d5d5dc7c110614ca10b5d98e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3475078 Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#79215}
2022-02-23 00:36:17 +00:00
"src/builtins/builtins-struct.cc",
"src/builtins/builtins-symbol.cc",
Reland "[Temporal] Part 1 - Skeleton" This is a reland of 0adc1410b1dae42b135b613ed86c18edafc83e3a 1. Fork out test/mjsunit/temporal/function-exist.js test to test/mjsunit/temporal/function-exist-no-i18n.js and mark function-exist FAIL in no_i18n build. Original change's description: > [Temporal] Part 1 - Skeleton > > 1. Expose all the functions to empty buildins. > 2. Wire up basic structure of classes and internal slots. > > Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/ > > This is just a CL to establish a skeleton for Temporal. > The Temporal is very big. The prototype CL is in > https://chromium-review.googlesource.com/c/v8/v8/+/2967755 > but too big to be reviewed so I break up the basic structure here first. > > Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel > Bug: v8:11544 > Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76819} Bug: v8:11544 Change-Id: I60eaface94ba9b3408cb235cd1ae425151a36732 Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324 Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77303}
2021-10-07 21:22:29 +00:00
"src/builtins/builtins-temporal.cc",
"src/builtins/builtins-trace.cc",
"src/builtins/builtins-typed-array.cc",
"src/builtins/builtins-weak-refs.cc",
"src/builtins/builtins-web-snapshots.cc",
"src/builtins/builtins.cc",
"src/builtins/constants-table-builder.cc",
Reland "Reland "Reland "[compiler][wasm] Align Frame slots to value size""" This is a reland of 352b9ecbdb090cbb22ee3362fadae28f86ba6773 The test/fix CL has been merged in, as the fixes to return slot accounting are needed to fix Arm64 issues turned up by the fuzzers: https://chromium-review.googlesource.com/c/v8/v8/+/2644139 The reverted fix for Wasm return slot allocation is added in patchset #2, to avoid fuzzer issues that it fixed: https://chromium-review.googlesource.com/c/v8/v8/+/2683024 TBR=neis@chromium.org Original change's description: > Reland "Reland "[compiler][wasm] Align Frame slots to value size"" > > This is a reland of 1694925c728a1be1b7084028bd656ddfc75f6471 > > Minor fix to linkage for constexpr. > > TBR=ahaas@chromium.org,neis@chromium.org > > Original change's description: > > Reland "[compiler][wasm] Align Frame slots to value size" > > > > This is a reland of cddaf66c371c2433c391434776f31b8771c5ab45 > > > > Original change's description: > > > [compiler][wasm] Align Frame slots to value size > > > > > > - Adds an AlignedSlotAllocator class and tests, to unify slot > > > allocation. This attempts to use alignment holes for smaller > > > values. > > > - Reworks Frame to use the new allocator for stack slots. > > > - Reworks LinkageAllocator to use the new allocator for stack > > > slots and for ARMv7 FP register aliasing. > > > - Fixes the RegisterAllocator to align spill slots. > > > - Fixes InstructionSelector to align spill slots. > > > > > > Bug: v8:9198 > > > > > > Change-Id: Ida148db428be89ef95de748ec5fc0e7b0358f523 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512840 > > > Commit-Queue: Bill Budge <bbudge@chromium.org> > > > Reviewed-by: Georg Neis <neis@chromium.org> > > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#71644} > > > > Bug: v8:9198 > > Change-Id: Ib91fa6746370c38496706341e12d05c7bf999389 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633390 > > Commit-Queue: Bill Budge <bbudge@chromium.org> > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#72195} > > Bug: v8:9198 > Change-Id: I91e02b823af8ec925dacf075388fb22e3eeb3384 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640890 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Commit-Queue: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72209} Bug: v8:9198 Change-Id: Ia5cf63af4e5991bc7cf42da9972ffd044fc829f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733177 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#73238}
2021-03-03 23:20:31 +00:00
"src/codegen/aligned-slot-allocator.cc",
"src/codegen/assembler.cc",
"src/codegen/bailout-reason.cc",
"src/codegen/code-comments.cc",
"src/codegen/code-desc.cc",
"src/codegen/code-factory.cc",
"src/codegen/code-reference.cc",
"src/codegen/compilation-cache.cc",
"src/codegen/compiler.cc",
"src/codegen/constant-pool.cc",
"src/codegen/external-reference-encoder.cc",
"src/codegen/external-reference-table.cc",
"src/codegen/external-reference.cc",
"src/codegen/flush-instruction-cache.cc",
"src/codegen/handler-table.cc",
"src/codegen/interface-descriptors.cc",
"src/codegen/machine-type.cc",
"src/codegen/maglev-safepoint-table.cc",
"src/codegen/optimized-compilation-info.cc",
"src/codegen/pending-optimization-table.cc",
"src/codegen/register-configuration.cc",
"src/codegen/reloc-info.cc",
"src/codegen/safepoint-table.cc",
"src/codegen/source-position-table.cc",
"src/codegen/source-position.cc",
"src/codegen/tick-counter.cc",
"src/codegen/tnode.cc",
"src/codegen/turbo-assembler.cc",
"src/codegen/unoptimized-compilation-info.cc",
"src/common/assert-scope.cc",
"src/common/code-memory-access.cc",
"src/common/ptr-compr.cc",
"src/compiler-dispatcher/lazy-compile-dispatcher.cc",
"src/compiler-dispatcher/optimizing-compile-dispatcher.cc",
"src/date/date.cc",
"src/date/dateparser.cc",
"src/debug/debug-coverage.cc",
"src/debug/debug-evaluate.cc",
"src/debug/debug-frames.cc",
"src/debug/debug-interface.cc",
"src/debug/debug-property-iterator.cc",
"src/debug/debug-scope-iterator.cc",
"src/debug/debug-scopes.cc",
"src/debug/debug-stack-trace-iterator.cc",
"src/debug/debug.cc",
"src/debug/liveedit-diff.cc",
"src/debug/liveedit.cc",
"src/deoptimizer/deoptimize-reason.cc",
"src/deoptimizer/deoptimized-frame-info.cc",
"src/deoptimizer/deoptimizer.cc",
"src/deoptimizer/materialized-object-store.cc",
"src/deoptimizer/translated-state.cc",
"src/deoptimizer/translation-array.cc",
"src/diagnostics/basic-block-profiler.cc",
"src/diagnostics/compilation-statistics.cc",
"src/diagnostics/disassembler.cc",
"src/diagnostics/eh-frame.cc",
"src/diagnostics/gdb-jit.cc",
"src/diagnostics/objects-debug.cc",
"src/diagnostics/objects-printer.cc",
"src/diagnostics/perf-jit.cc",
"src/diagnostics/unwinder.cc",
"src/execution/arguments.cc",
"src/execution/clobber-registers.cc",
Reland "[profiler] Surface VM & Embedder State" This is a reland of 2d087f237eadd78f5545548675642f013fdfe675 The changes are : * Fix redundant reinterpret_cast in test file for MSVC failure https://crbug.com/v8/12476 * Fix flaky test https://crbug.com/v8/12475 If a sample is captured during a GC, no embedder context is obtained defaulting to EMPTY. This is the expected behavior, made it in clear in implementation and in test. * Synchronized the embedder context filter behavior with existing native context filter. Original change's description: > Add APIs to surface VMState and new EmbedderState to CpuProfile samples. > > EmbedderState: > * An EmbedderState is defined as a value uint8_t and a v8::context used > for filtering. > * EmbedderStates are stack allocated by the embedder, construction and > destruction set/unset the state to the isolate thread local top. > * A v8::context is used to filter states that are added to a CpuProfile, > if the CpuProfile do not have a ContextFilter set or if contexts do not > match, state defaults to Empty. > > * v8:StateTag is already propagated all the way to a Sample, simply add > an API to surface it. > > VMState: > Change-Id: I7eed08907360b99b0ad20ddcff59c95c7076c85e > Bug: chromium:1263871 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3188072 > Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Camillo Bruni <cbruni@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78250} Bug: chromium:1263871 Change-Id: Ief891b05da99c695e9fb70f94ed7ebdecc6c3b7b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320037 Auto-Submit: Corentin Pescheloche <cpescheloche@fb.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78281}
2021-12-07 07:28:08 +00:00
"src/execution/embedder-state.cc",
Reland^2 "[fastcall] Enable float support on arm64 simulator"" This is a reland of d7c3f1cd8a2450afdfe592f87c67cead3a00b88e. It fixes a build failure on native arm64. Original change's description: > Reland "[fastcall] Enable float support on arm64 simulator" > > This is a reland of b9ddcbc86f76fb393e9343162348e976ae6d3a33 > > The original CL was reverted due to an MSAN issue, that is fixed by > moving the signature mapping onto the Isolate (instead of having > per-thread storage, which got invalid on multithreaded compilation). > > This CL also contains fixes for the Bazel config and for a data race > when obtaining the PerIsolateSimulatorData. > > Original change's description: > > [fastcall] Enable float support on arm64 simulator > > > > This CL adds support for handling calls to C functions with arbitrary > > signatures on the arm64 simulator. It adds infrastructure for > > encoding the signature data from CallDescriptor and FunctionInfo > > classes into a compact representation, stored in the simulator and > > called EncodedCSignature. > > > > Design doc: > > https://docs.google.com/document/d/1ZxOF3GSyNmtU0C0YJvrsydPJj35W_tTJZymeXwfDxoI/edit > > > > This CL is a follow up on the native support added in > > https://chromium-review.googlesource.com/c/v8/v8/+/3182232 > > and is partially based on the previous attempt: > > https://chromium-review.googlesource.com/c/v8/v8/+/2343072 > > > > Bug: chromium:1052746 > > Change-Id: I0991b47bd644b2fc2244c5eb923b085261f04765 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060486 > > Commit-Queue: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#77744} > > Bug: chromium:1052746, chromium:1267854 > Change-Id: I89bbd01e33fb1080543d98bcfd4c2d17b5c76861 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3270541 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78018} Bug: chromium:1052746, chromium:1267854 Change-Id: Ib495573569a6c930b8f9e5f1fe7ff46eb57a0aa7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3295461 Auto-Submit: Maya Lekova <mslekova@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#78063}
2021-11-22 17:10:53 +00:00
"src/execution/encoded-c-signature.cc",
"src/execution/execution.cc",
"src/execution/frames.cc",
"src/execution/futex-emulation.cc",
"src/execution/interrupts-scope.cc",
"src/execution/isolate.cc",
"src/execution/local-isolate.cc",
"src/execution/messages.cc",
"src/execution/microtask-queue.cc",
"src/execution/protectors.cc",
"src/execution/simulator-base.cc",
"src/execution/stack-guard.cc",
"src/execution/thread-id.cc",
"src/execution/thread-local-top.cc",
"src/execution/tiering-manager.cc",
"src/execution/v8threads.cc",
"src/extensions/cputracemark-extension.cc",
"src/extensions/externalize-string-extension.cc",
"src/extensions/gc-extension.cc",
"src/extensions/ignition-statistics-extension.cc",
"src/extensions/statistics-extension.cc",
"src/extensions/trigger-failure-extension.cc",
"src/flags/flags.cc",
"src/handles/global-handles.cc",
"src/handles/handles.cc",
"src/handles/local-handles.cc",
"src/handles/persistent-handles.cc",
"src/handles/shared-object-conveyor-handles.cc",
"src/handles/traced-handles.cc",
"src/heap/allocation-observer.cc",
"src/heap/array-buffer-sweeper.cc",
"src/heap/base-space.cc",
"src/heap/basic-memory-chunk.cc",
"src/heap/code-object-registry.cc",
"src/heap/code-range.cc",
"src/heap/code-stats.cc",
"src/heap/collection-barrier.cc",
"src/heap/combined-heap.cc",
"src/heap/concurrent-allocator.cc",
"src/heap/concurrent-marking.cc",
"src/heap/cppgc-js/cpp-heap.cc",
"src/heap/cppgc-js/cpp-snapshot.cc",
"src/heap/cppgc-js/cross-heap-remembered-set.cc",
Reland "cppgc-js: Concurrently process v8::TracedReference" This is a reland of commit 1f0d7d207260e32f17931b1aa89e71d490f9d460 The fix merges concurrent marking tasks when marking in the atomic pause. Without the fix, Oilpan markers would continue running concurrently, possibly discovering new V8 objects. This violates the assumption that the final transitive closure runs on a single thread. Original change's description: > cppgc-js: Concurrently process v8::TracedReference > > Adds concurrent marking for reaching through v8::TracedReference. > Before this CL, a v8::TracedReference would always be processed on the > main thread by pushing a callback for each encountered reference. > > This CL now wires up concurrent handling for such references. In particular: > - Global handles are already marked as well and not repurposed during > the same GC cycle. > - Since global handles are not repurposed, it is enough to > double-deref to the V8 object, checking for possible null pointers. > - The bitmap for global handle flags is mostly non-atomic, with the > markbit being the exception. > - Finally, all state is wired up in CppHeap. Concurrent markers keep > their own local worklist while the mutator marker directly pushes to > the worklist owned by V8. > > Bug: v8:12600 > Change-Id: Ia67dbd18a57dbcccf4dfb9ccfdb9ee438d27fe71 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516255 > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79736} Bug: v8:12600 Change-Id: I8545041b2c7b3daf7ecea7e3a100e27534e9b8b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571887 Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#79919}
2022-04-11 13:24:03 +00:00
"src/heap/cppgc-js/unified-heap-marking-state.cc",
"src/heap/cppgc-js/unified-heap-marking-verifier.cc",
"src/heap/cppgc-js/unified-heap-marking-visitor.cc",
"src/heap/embedder-tracing.cc",
"src/heap/evacuation-verifier.cc",
"src/heap/factory-base.cc",
"src/heap/factory.cc",
"src/heap/finalization-registry-cleanup-task.cc",
"src/heap/free-list.cc",
"src/heap/gc-idle-time-handler.cc",
"src/heap/gc-tracer.cc",
"src/heap/heap-allocator.cc",
"src/heap/heap-controller.cc",
"src/heap/heap-layout-tracer.cc",
"src/heap/heap-verifier.cc",
"src/heap/heap-write-barrier.cc",
"src/heap/heap.cc",
"src/heap/incremental-marking-job.cc",
"src/heap/incremental-marking.cc",
"src/heap/index-generator.cc",
"src/heap/invalidated-slots.cc",
"src/heap/large-spaces.cc",
"src/heap/local-factory.cc",
"src/heap/local-heap.cc",
"src/heap/mark-compact.cc",
"src/heap/marking-barrier.cc",
"src/heap/marking-worklist.cc",
"src/heap/marking.cc",
"src/heap/memory-allocator.cc",
"src/heap/memory-chunk-layout.cc",
"src/heap/memory-chunk.cc",
"src/heap/memory-measurement.cc",
"src/heap/memory-reducer.cc",
"src/heap/new-spaces.cc",
"src/heap/object-stats.cc",
"src/heap/objects-visiting.cc",
"src/heap/paged-spaces.cc",
"src/heap/pretenuring-handler.cc",
"src/heap/read-only-heap.cc",
"src/heap/read-only-spaces.cc",
"src/heap/safepoint.cc",
"src/heap/scavenge-job.cc",
"src/heap/scavenger.cc",
"src/heap/slot-set.cc",
"src/heap/spaces.cc",
"src/heap/stress-marking-observer.cc",
"src/heap/stress-scavenge-observer.cc",
"src/heap/sweeper.cc",
"src/heap/traced-handles-marking-visitor.cc",
"src/heap/weak-object-worklists.cc",
"src/ic/call-optimization.cc",
"src/ic/handler-configuration.cc",
"src/ic/ic-stats.cc",
"src/ic/ic.cc",
"src/ic/stub-cache.cc",
"src/init/bootstrapper.cc",
"src/init/icu_util.cc",
"src/init/isolate-allocator.cc",
"src/init/startup-data-util.cc",
"src/init/v8.cc",
"src/interpreter/bytecode-array-builder.cc",
"src/interpreter/bytecode-array-iterator.cc",
"src/interpreter/bytecode-array-random-iterator.cc",
"src/interpreter/bytecode-array-writer.cc",
"src/interpreter/bytecode-decoder.cc",
"src/interpreter/bytecode-flags.cc",
"src/interpreter/bytecode-generator.cc",
"src/interpreter/bytecode-label.cc",
"src/interpreter/bytecode-node.cc",
"src/interpreter/bytecode-operands.cc",
"src/interpreter/bytecode-register-optimizer.cc",
"src/interpreter/bytecode-register.cc",
"src/interpreter/bytecode-source-info.cc",
"src/interpreter/bytecodes.cc",
"src/interpreter/constant-array-builder.cc",
"src/interpreter/control-flow-builders.cc",
"src/interpreter/handler-table-builder.cc",
"src/interpreter/interpreter-intrinsics.cc",
"src/interpreter/interpreter.cc",
"src/json/json-parser.cc",
"src/json/json-stringifier.cc",
"src/libsampler/sampler.cc",
"src/logging/counters.cc",
"src/logging/local-logger.cc",
"src/logging/log-file.cc",
"src/logging/log.cc",
"src/logging/metrics.cc",
"src/logging/runtime-call-stats.cc",
"src/logging/tracing-flags.cc",
"src/numbers/conversions.cc",
"src/numbers/math-random.cc",
"src/objects/backing-store.cc",
"src/objects/bigint.cc",
"src/objects/call-site-info.cc",
"src/objects/code-kind.cc",
"src/objects/code.cc",
"src/objects/compilation-cache-table.cc",
"src/objects/contexts.cc",
"src/objects/debug-objects.cc",
"src/objects/elements-kind.cc",
"src/objects/elements.cc",
"src/objects/embedder-data-array.cc",
"src/objects/feedback-vector.cc",
"src/objects/field-type.cc",
"src/objects/intl-objects.cc",
"src/objects/js-array-buffer.cc",
"src/objects/js-atomics-synchronization.cc",
"src/objects/js-break-iterator.cc",
"src/objects/js-collator.cc",
"src/objects/js-date-time-format.cc",
"src/objects/js-display-names.cc",
"src/objects/js-duration-format.cc",
"src/objects/js-function.cc",
"src/objects/js-list-format.cc",
"src/objects/js-locale.cc",
"src/objects/js-number-format.cc",
"src/objects/js-objects.cc",
"src/objects/js-plural-rules.cc",
"src/objects/js-raw-json.cc",
"src/objects/js-regexp.cc",
"src/objects/js-relative-time-format.cc",
"src/objects/js-segment-iterator.cc",
"src/objects/js-segmenter.cc",
"src/objects/js-segments.cc",
"src/objects/js-temporal-objects.cc",
"src/objects/keys.cc",
"src/objects/literal-objects.cc",
"src/objects/lookup-cache.cc",
"src/objects/lookup.cc",
"src/objects/managed.cc",
"src/objects/map-updater.cc",
"src/objects/map.cc",
"src/objects/module.cc",
"src/objects/object-type.cc",
"src/objects/objects.cc",
"src/objects/option-utils.cc",
"src/objects/ordered-hash-table.cc",
"src/objects/property-descriptor.cc",
"src/objects/property.cc",
"src/objects/scope-info.cc",
"src/objects/shared-function-info.cc",
"src/objects/simd.cc",
"src/objects/source-text-module.cc",
"src/objects/string-comparator.cc",
"src/objects/string-forwarding-table.cc",
"src/objects/string-table.cc",
"src/objects/string.cc",
"src/objects/swiss-name-dictionary.cc",
"src/objects/symbol-table.cc",
"src/objects/synthetic-module.cc",
"src/objects/tagged-impl.cc",
"src/objects/template-objects.cc",
"src/objects/templates.cc",
"src/objects/transitions.cc",
"src/objects/type-hints.cc",
"src/objects/value-serializer.cc",
"src/objects/visitors.cc",
"src/parsing/func-name-inferrer.cc",
"src/parsing/import-assertions.cc",
"src/parsing/literal-buffer.cc",
"src/parsing/parse-info.cc",
"src/parsing/parser.cc",
"src/parsing/parsing.cc",
"src/parsing/pending-compilation-error-handler.cc",
"src/parsing/preparse-data.cc",
"src/parsing/preparser.cc",
"src/parsing/rewriter.cc",
"src/parsing/scanner-character-streams.cc",
"src/parsing/scanner.cc",
"src/parsing/token.cc",
"src/profiler/allocation-tracker.cc",
"src/profiler/cpu-profiler.cc",
"src/profiler/heap-profiler.cc",
"src/profiler/heap-snapshot-generator.cc",
"src/profiler/profile-generator.cc",
"src/profiler/profiler-listener.cc",
"src/profiler/profiler-stats.cc",
"src/profiler/sampling-heap-profiler.cc",
"src/profiler/strings-storage.cc",
"src/profiler/symbolizer.cc",
"src/profiler/tick-sample.cc",
"src/profiler/tracing-cpu-profiler.cc",
"src/profiler/weak-code-registry.cc",
"src/regexp/experimental/experimental-bytecode.cc",
"src/regexp/experimental/experimental-compiler.cc",
"src/regexp/experimental/experimental-interpreter.cc",
"src/regexp/experimental/experimental.cc",
"src/regexp/regexp-ast.cc",
"src/regexp/regexp-bytecode-generator.cc",
Reland "[regexp] Bytecode peephole optimization" This is a reland of 6612943010eca49e9ce262796e871e3d22999154 Fixed: Unaligned reads, unspecified evaluation order. Original change's description: > [regexp] Bytecode peephole optimization > > Bytecodes used by the regular expression interpreter often occur in > specific sequences. The number of dispatches in the interpreter can be > reduced if those sequences are combined into a single bytecode. > > This CL adds a peephole optimization pass for regexp bytecodes. > This pass checks the generated bytecode for pre-defined sequences that > can be merged into a single bytecode. > > With the currently implemented bytecode sequences a speedup of 1.12x on > regex-dna and octane-regexp is achieved. > > Bug: v8:9330 > Change-Id: I827f93273a5848e5963c7e3329daeb898995d151 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1813743 > Commit-Queue: Patrick Thier <pthier@google.com> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63992} Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux_gcc_rel Bug: v8:9330,chromium:1008502,chromium:1008631 Change-Id: Ib9fc395b6809aa1debdb54d9fba5b7f09a235e5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1828917 Reviewed-by: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64064}
2019-10-01 11:55:16 +00:00
"src/regexp/regexp-bytecode-peephole.cc",
"src/regexp/regexp-bytecodes.cc",
"src/regexp/regexp-compiler-tonode.cc",
"src/regexp/regexp-compiler.cc",
"src/regexp/regexp-dotprinter.cc",
Reland "[regexp] Rewrite error handling" This is a reland of e80ca24c80432f747c386da61459282d44ba7aaa Original change's description: > [regexp] Rewrite error handling > > This patch modifies irregexp's error handling. Instead of representing > errors as C strings, they are represented as an enumeration value > (RegExpError), and only converted to strings when throwing the error > object in regexp.cc. This makes it significantly easier to integrate > into SpiderMonkey. A few notes: > > 1. Depending on whether the stack overflows during parsing or > analysis, the stack overflow message can vary ("Stack overflow" or > "Maximum call stack size exceeded"). I kept that behaviour in this > patch, under the assumption that stack overflow messages are > (sadly) the sorts of things that real world code ends up depending > on. > > 2. Depending on the point in code where the error was identified, > invalid unicode escapes could be reported as "Invalid Unicode > escape", "Invalid unicode escape", or "Invalid Unicode escape > sequence". I fervently hope that nobody depends on the specific > wording of a syntax error, so I standardized on the first one. (It > was both the most common, and the most consistent with other > "Invalid X escape" messages.) > > 3. In addition to changing the representation, this patch also adds an > error_pos field to RegExpParser and RegExpCompileData, which stores > the position at which an error occurred. This is used by > SpiderMonkey to provide more helpful messages about where a syntax > error occurred in large regular expressions. > > 4. This model is closer to V8's existing MessageTemplate > infrastructure. I considered trying to integrate it more closely > with MessageTemplate, but since one of our stated goals for this > project was to make it easier to use irregexp outside of V8, I > decided to hold off. > > R=jgruber@chromium.org > > Bug: v8:10303 > Change-Id: I62605fd2def2fc539f38a7e0eefa04d36e14bbde > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2091863 > Commit-Queue: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66784} R=jgruber@chromium.org Bug: v8:10303 Change-Id: Iad1f11a0e0b9e525d7499aacb56c27eff9e7c7b5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2109952 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66798}
2020-03-19 14:02:33 +00:00
"src/regexp/regexp-error.cc",
"src/regexp/regexp-interpreter.cc",
"src/regexp/regexp-macro-assembler-tracer.cc",
"src/regexp/regexp-macro-assembler.cc",
"src/regexp/regexp-parser.cc",
"src/regexp/regexp-stack.cc",
"src/regexp/regexp-utils.cc",
"src/regexp/regexp.cc",
"src/roots/roots.cc",
"src/runtime/runtime-array.cc",
"src/runtime/runtime-atomics.cc",
"src/runtime/runtime-bigint.cc",
"src/runtime/runtime-classes.cc",
"src/runtime/runtime-collections.cc",
"src/runtime/runtime-compiler.cc",
"src/runtime/runtime-date.cc",
"src/runtime/runtime-debug.cc",
"src/runtime/runtime-forin.cc",
"src/runtime/runtime-function.cc",
"src/runtime/runtime-futex.cc",
"src/runtime/runtime-generator.cc",
"src/runtime/runtime-internal.cc",
"src/runtime/runtime-intl.cc",
"src/runtime/runtime-literals.cc",
"src/runtime/runtime-module.cc",
"src/runtime/runtime-numbers.cc",
"src/runtime/runtime-object.cc",
"src/runtime/runtime-operators.cc",
"src/runtime/runtime-promise.cc",
"src/runtime/runtime-proxy.cc",
"src/runtime/runtime-regexp.cc",
"src/runtime/runtime-scopes.cc",
"src/runtime/runtime-shadow-realm.cc",
"src/runtime/runtime-strings.cc",
"src/runtime/runtime-symbol.cc",
"src/runtime/runtime-temporal.cc",
"src/runtime/runtime-test.cc",
"src/runtime/runtime-trace.cc",
"src/runtime/runtime-typedarray.cc",
"src/runtime/runtime-weak-refs.cc",
"src/runtime/runtime.cc",
V8 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
"src/sandbox/external-pointer-table.cc",
"src/sandbox/sandbox.cc",
"src/sandbox/testing.cc",
"src/snapshot/code-serializer.cc",
"src/snapshot/context-deserializer.cc",
"src/snapshot/context-serializer.cc",
"src/snapshot/deserializer.cc",
"src/snapshot/embedded/embedded-data.cc",
"src/snapshot/object-deserializer.cc",
"src/snapshot/read-only-deserializer.cc",
"src/snapshot/read-only-serializer.cc",
"src/snapshot/roots-serializer.cc",
"src/snapshot/serializer-deserializer.cc",
"src/snapshot/serializer.cc",
"src/snapshot/shared-heap-deserializer.cc",
"src/snapshot/shared-heap-serializer.cc",
"src/snapshot/snapshot-data.cc",
"src/snapshot/snapshot-source-sink.cc",
"src/snapshot/snapshot-utils.cc",
"src/snapshot/snapshot.cc",
"src/snapshot/startup-deserializer.cc",
"src/snapshot/startup-serializer.cc",
"src/strings/char-predicates.cc",
"src/strings/string-builder.cc",
"src/strings/string-case.cc",
"src/strings/string-stream.cc",
"src/strings/unicode-decoder.cc",
"src/strings/unicode.cc",
"src/strings/uri.cc",
"src/tasks/cancelable-task.cc",
Reland "Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob."" This is a reland of 064ee3c8358195dfce7f34e4deaa3f74f0caa325 Issue 1: WasmEngine UAF when CompilationState is destroyed asynchronously Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508 in this CL. Use OperationBarrier to keep WasmEngine alive. Issue 2: In gin, JobTask lifetime is not extended beyond JobHandle, thus making CancelAndDetach unusable. This is fixed in chromium here: https://chromium-review.googlesource.com/c/chromium/src/+/2566724 Original change's description: > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob." > > Reason for revert: Data race: > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121 > > It was assume that MockPlatform runs everything on 1 thread. However, > MockPlatform::PostJob previously would schedule the job through > TestPlatform, which eventually posts concurrent tasks, thus causing > data race. > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform > ensures the jobs also run sequentially. > > Additional change: > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure > it's called in sequence with ScheduleCompileJobForNewUnits > > Original CL description: > To avoid keeping around a list of job handles, CancelAndDetach() is > used in CancelCompilation. Dependency on WasmEngine is handled by a > barrier that waits on all jobs to finish. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Original-Commit-Position: refs/heads/master@{#71074} > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71459} TBR=ulan@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: I6175092c97fea0d5f63a97af232e2d54cccea535 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71662}
2020-12-02 16:29:08 +00:00
"src/tasks/operations-barrier.cc",
"src/tasks/task-utils.cc",
"src/temporal/temporal-parser.cc",
"src/third_party/siphash/halfsiphash.cc",
"src/tracing/trace-event.cc",
"src/tracing/traced-value.cc",
"src/tracing/tracing-category-observer.cc",
"src/utils/address-map.cc",
"src/utils/allocation.cc",
"src/utils/bit-vector.cc",
"src/utils/detachable-vector.cc",
"src/utils/identity-map.cc",
"src/utils/memcopy.cc",
"src/utils/ostreams.cc",
"src/utils/utils.cc",
"src/utils/version.cc",
"src/web-snapshot/web-snapshot.cc",
"src/web-snapshot/web-snapshot.h",
"src/zone/accounting-allocator.cc",
"src/zone/type-stats.cc",
"src/zone/zone-segment.cc",
"src/zone/zone.cc",
]
if (v8_enable_snapshot_compression) {
sources += [ "src/snapshot/snapshot-compression.cc" ]
}
if (v8_enable_maglev) {
sources += [
"src/maglev/maglev-code-generator.cc",
"src/maglev/maglev-compilation-info.cc",
"src/maglev/maglev-compilation-unit.cc",
"src/maglev/maglev-compiler.cc",
"src/maglev/maglev-concurrent-dispatcher.cc",
"src/maglev/maglev-graph-builder.cc",
"src/maglev/maglev-graph-printer.cc",
"src/maglev/maglev-interpreter-frame-state.cc",
"src/maglev/maglev-ir.cc",
"src/maglev/maglev-regalloc.cc",
"src/maglev/maglev.cc",
]
if (v8_current_cpu == "arm64") {
sources += [
"src/maglev/arm64/maglev-assembler-arm64.cc",
"src/maglev/arm64/maglev-ir-arm64.cc",
]
} else if (v8_current_cpu == "x64") {
sources += [
"src/maglev/x64/maglev-assembler-x64.cc",
"src/maglev/x64/maglev-ir-x64.cc",
]
}
}
if (v8_enable_webassembly) {
sources += [
### gcmole(all) ###
"src/asmjs/asm-js.cc",
"src/asmjs/asm-parser.cc",
"src/asmjs/asm-scanner.cc",
"src/asmjs/asm-types.cc",
"src/debug/debug-wasm-objects.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/runtime/runtime-test-wasm.cc",
"src/runtime/runtime-wasm.cc",
"src/trap-handler/handler-inside.cc",
"src/trap-handler/handler-outside.cc",
"src/trap-handler/handler-shared.cc",
"src/wasm/assembler-buffer-cache.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/baseline/liftoff-assembler.cc",
"src/wasm/baseline/liftoff-compiler.cc",
"src/wasm/canonical-types.cc",
"src/wasm/code-space-access.cc",
"src/wasm/constant-expression-interface.cc",
"src/wasm/constant-expression.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/function-body-decoder.cc",
"src/wasm/function-compiler.cc",
"src/wasm/graph-builder-interface.cc",
"src/wasm/jump-table-assembler.cc",
"src/wasm/local-decl-encoder.cc",
"src/wasm/memory-tracing.cc",
"src/wasm/module-compiler.cc",
"src/wasm/module-decoder.cc",
"src/wasm/module-instantiate.cc",
"src/wasm/names-provider.cc",
"src/wasm/pgo.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/simd-shuffle.cc",
"src/wasm/stacks.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/streaming-decoder.cc",
"src/wasm/sync-streaming-decoder.cc",
"src/wasm/value-type.cc",
"src/wasm/wasm-code-manager.cc",
"src/wasm/wasm-debug.cc",
"src/wasm/wasm-disassembler.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/wasm-engine.cc",
"src/wasm/wasm-external-refs.cc",
"src/wasm/wasm-features.cc",
"src/wasm/wasm-import-wrapper-cache.cc",
"src/wasm/wasm-init-expr.cc",
"src/wasm/wasm-js.cc",
Reland "[no-wasm] Exclude src/wasm from compilation" This is a reland of 80f5dfda0147d6b078ae6c9d0eb947bd012bf72d. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
2021-03-11 13:42:01 +00:00
"src/wasm/wasm-module-builder.cc",
"src/wasm/wasm-module-sourcemap.cc",
"src/wasm/wasm-module.cc",
"src/wasm/wasm-objects.cc",
"src/wasm/wasm-opcodes.cc",
"src/wasm/wasm-result.cc",
"src/wasm/wasm-serialization.cc",
"src/wasm/wasm-subtyping.cc",
]
}
if (v8_enable_third_party_heap) {
sources += filter_exclude(v8_third_party_heap_files, [ "*.h" ])
} else {
sources += [ "src/heap/third-party/heap-api-stub.cc" ]
}
[heap] Add object start bitmap for conservative stack scanning With conservative stack scanning enabled, a snapshot of the call stack upon entry to GC will be used to determine part of the root-set. When the collector walks the stack, it looks at each value and determines whether it could be a potential on-heap object pointer. However, unlike with Handles, these on-stack pointers aren't guaranteed to point to the start of the object: the compiler may decide hide these pointers, and create interior pointers in C++ frames which the GC doesn't know about. The solution to this is to include an object start bitmap in the header of each page. Each bit in the bitmap represents a word in the page payload which is set when an object is allocated. This means that when the collector finds an arbitrary potential pointer into the page, it can walk backwards through the bitmap until it finds the relevant object's base pointer. To prevent the bitmap becoming stale after compaction, it is rebuilt during object sweeping. This is experimental, and currently only works with inline allocation disabled, and single generational collection. Bug: v8:10614 Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#69615}
2020-08-28 20:48:41 +00:00
if (v8_enable_conservative_stack_scanning) {
sources += [ "src/heap/conservative-stack-visitor.cc" ]
[heap] Add object start bitmap for conservative stack scanning With conservative stack scanning enabled, a snapshot of the call stack upon entry to GC will be used to determine part of the root-set. When the collector walks the stack, it looks at each value and determines whether it could be a potential on-heap object pointer. However, unlike with Handles, these on-stack pointers aren't guaranteed to point to the start of the object: the compiler may decide hide these pointers, and create interior pointers in C++ frames which the GC doesn't know about. The solution to this is to include an object start bitmap in the header of each page. Each bit in the bitmap represents a word in the page payload which is set when an object is allocated. This means that when the collector finds an arbitrary potential pointer into the page, it can walk backwards through the bitmap until it finds the relevant object's base pointer. To prevent the bitmap becoming stale after compaction, it is rebuilt during object sweeping. This is experimental, and currently only works with inline allocation disabled, and single generational collection. Bug: v8:10614 Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#69615}
2020-08-28 20:48:41 +00:00
}
Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub This is the first piece of the wasm debugging prototype (besides the changes to add/remove breakpoints in WasmModuleObject made with https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737). This changelist adds the infrastructure for a GDB-remote stub that will be used to manage debugging sessions via the gdb-remote protocol. It enables the creation and termination of debugging sessions over TCP connections that are managed in a separate thread. The logic to actually send, receive and decode GDB-remote packets will be part of a future changelist. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Enables Wasm debugging with LLDB (default: false) --wasm-gdb-remote-port TCP port to be used for debugging (default: 8765) --wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting for a debugger (default: false) --trace-wasm-gdb-remote Enables tracing of Gdb-remote packets (default: false) Note that most of this code is "borrowed" from the code of the Chromium NaCL GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub). Implementation details: - class GdbServer acts as a singleton manager for the gdb-remote stub. It is instantiated as soon as the first Wasm module is loaded in the Wasm engine. - class GdbServerThread spawns the worker thread for the TCP connection. - class Transport manages the socket connection, in a portable way. - class Session represents a remote debugging session. - class Target represents a debugging target and it’s the place where the debugging packets will be processed and will implement the logic to debug a Wasm engine. Bug: chromium:1010467 Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66379}
2020-02-17 05:01:29 +00:00
if (v8_enable_wasm_gdb_remote_debugging) {
sources += [
"src/debug/wasm/gdb-server/gdb-remote-util.cc",
Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub This is the first piece of the wasm debugging prototype (besides the changes to add/remove breakpoints in WasmModuleObject made with https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737). This changelist adds the infrastructure for a GDB-remote stub that will be used to manage debugging sessions via the gdb-remote protocol. It enables the creation and termination of debugging sessions over TCP connections that are managed in a separate thread. The logic to actually send, receive and decode GDB-remote packets will be part of a future changelist. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Enables Wasm debugging with LLDB (default: false) --wasm-gdb-remote-port TCP port to be used for debugging (default: 8765) --wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting for a debugger (default: false) --trace-wasm-gdb-remote Enables tracing of Gdb-remote packets (default: false) Note that most of this code is "borrowed" from the code of the Chromium NaCL GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub). Implementation details: - class GdbServer acts as a singleton manager for the gdb-remote stub. It is instantiated as soon as the first Wasm module is loaded in the Wasm engine. - class GdbServerThread spawns the worker thread for the TCP connection. - class Transport manages the socket connection, in a portable way. - class Session represents a remote debugging session. - class Target represents a debugging target and it’s the place where the debugging packets will be processed and will implement the logic to debug a Wasm engine. Bug: chromium:1010467 Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66379}
2020-02-17 05:01:29 +00:00
"src/debug/wasm/gdb-server/gdb-server-thread.cc",
"src/debug/wasm/gdb-server/gdb-server.cc",
"src/debug/wasm/gdb-server/packet.cc",
Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub This is the first piece of the wasm debugging prototype (besides the changes to add/remove breakpoints in WasmModuleObject made with https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737). This changelist adds the infrastructure for a GDB-remote stub that will be used to manage debugging sessions via the gdb-remote protocol. It enables the creation and termination of debugging sessions over TCP connections that are managed in a separate thread. The logic to actually send, receive and decode GDB-remote packets will be part of a future changelist. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Enables Wasm debugging with LLDB (default: false) --wasm-gdb-remote-port TCP port to be used for debugging (default: 8765) --wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting for a debugger (default: false) --trace-wasm-gdb-remote Enables tracing of Gdb-remote packets (default: false) Note that most of this code is "borrowed" from the code of the Chromium NaCL GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub). Implementation details: - class GdbServer acts as a singleton manager for the gdb-remote stub. It is instantiated as soon as the first Wasm module is loaded in the Wasm engine. - class GdbServerThread spawns the worker thread for the TCP connection. - class Transport manages the socket connection, in a portable way. - class Session represents a remote debugging session. - class Target represents a debugging target and it’s the place where the debugging packets will be processed and will implement the logic to debug a Wasm engine. Bug: chromium:1010467 Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66379}
2020-02-17 05:01:29 +00:00
"src/debug/wasm/gdb-server/session.cc",
"src/debug/wasm/gdb-server/target.cc",
"src/debug/wasm/gdb-server/transport.cc",
"src/debug/wasm/gdb-server/wasm-module-debug.cc",
Add initial support for Wasm debugging with LLDB: implements a GDB-remote stub This is the first piece of the wasm debugging prototype (besides the changes to add/remove breakpoints in WasmModuleObject made with https://chromium.googlesource.com/v8/v8.git/+/e699f39caed9a23f8e20bd3a0386a3236e272737). This changelist adds the infrastructure for a GDB-remote stub that will be used to manage debugging sessions via the gdb-remote protocol. It enables the creation and termination of debugging sessions over TCP connections that are managed in a separate thread. The logic to actually send, receive and decode GDB-remote packets will be part of a future changelist. Build with: v8_enable_wasm_gdb_remote_debugging = true Run with: --wasm-gdb-remote Enables Wasm debugging with LLDB (default: false) --wasm-gdb-remote-port TCP port to be used for debugging (default: 8765) --wasm-pause-waiting-for-debugger Pauses the execution of Wasm code waiting for a debugger (default: false) --trace-wasm-gdb-remote Enables tracing of Gdb-remote packets (default: false) Note that most of this code is "borrowed" from the code of the Chromium NaCL GDB-remote stub (located in Chromium in src\native_client\src\trusted\debug_stub). Implementation details: - class GdbServer acts as a singleton manager for the gdb-remote stub. It is instantiated as soon as the first Wasm module is loaded in the Wasm engine. - class GdbServerThread spawns the worker thread for the TCP connection. - class Transport manages the socket connection, in a portable way. - class Session represents a remote debugging session. - class Target represents a debugging target and it’s the place where the debugging packets will be processed and will implement the logic to debug a Wasm engine. Bug: chromium:1010467 Change-Id: Ib2324e5901f5ae1d855b96b99ef0995d407322b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1923407 Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66379}
2020-02-17 05:01:29 +00:00
]
}
if (v8_enable_heap_snapshot_verify) {
sources += [ "src/heap/reference-summarizer.cc" ]
}
if (v8_current_cpu == "x86") {
sources += [
### gcmole(ia32) ###
"src/codegen/ia32/assembler-ia32.cc",
"src/codegen/ia32/cpu-ia32.cc",
"src/codegen/ia32/macro-assembler-ia32.cc",
"src/codegen/shared-ia32-x64/macro-assembler-shared-ia32-x64.cc",
"src/compiler/backend/ia32/code-generator-ia32.cc",
"src/compiler/backend/ia32/instruction-scheduler-ia32.cc",
"src/compiler/backend/ia32/instruction-selector-ia32.cc",
"src/deoptimizer/ia32/deoptimizer-ia32.cc",
"src/diagnostics/ia32/disasm-ia32.cc",
"src/diagnostics/ia32/unwinder-ia32.cc",
"src/execution/ia32/frame-constants-ia32.cc",
"src/regexp/ia32/regexp-macro-assembler-ia32.cc",
]
} else if (v8_current_cpu == "x64") {
sources += [
### gcmole(x64) ###
"src/codegen/shared-ia32-x64/macro-assembler-shared-ia32-x64.cc",
"src/codegen/x64/assembler-x64.cc",
"src/codegen/x64/cpu-x64.cc",
"src/codegen/x64/macro-assembler-x64.cc",
"src/compiler/backend/x64/code-generator-x64.cc",
"src/compiler/backend/x64/instruction-scheduler-x64.cc",
"src/compiler/backend/x64/instruction-selector-x64.cc",
"src/compiler/backend/x64/unwinding-info-writer-x64.cc",
"src/deoptimizer/x64/deoptimizer-x64.cc",
"src/diagnostics/x64/disasm-x64.cc",
"src/diagnostics/x64/eh-frame-x64.cc",
"src/diagnostics/x64/unwinder-x64.cc",
"src/execution/x64/frame-constants-x64.cc",
"src/regexp/x64/regexp-macro-assembler-x64.cc",
]
2021-06-11 18:05:23 +00:00
if (is_win) {
sources += [ "src/diagnostics/unwinding-info-win64.cc" ]
}
if (v8_enable_webassembly) {
# iOS Xcode simulator builds run on an x64 target. iOS and macOS are both
# based on Darwin and thus POSIX-compliant to a similar degree.
if (is_linux || is_chromeos || is_mac || is_ios ||
target_os == "freebsd") {
sources += [
"src/trap-handler/handler-inside-posix.cc",
"src/trap-handler/handler-outside-posix.cc",
]
} else if (is_win) {
sources += [
"src/trap-handler/handler-inside-win.cc",
"src/trap-handler/handler-outside-win.cc",
]
}
[wasm] Initial signal handler This is basically the minimum viable signal handler for Wasm bounds checks. It includes the TLS check and the fine grained instructions checks. These two checks provide most of the safety for the signal handler. Future CLs will add code range and data range checks for more robustness. The trap handling code and data structures are all in src/trap-handler, with the code that actually runs in the signal handler confined to src/trap-handler/signal-handler.cc. This changes adds a new V8 API that the embedder should call from a signal handler that will give V8 the chance to handle the fault first. For hosts that do not want to implement their own signal handler, we include the option to install a simple one. This simple handler is also used for the tests. When a Wasm module is instantiated, information about each function is passed to the trap handler, which is used to classify faults. These are removed during the instance finalizer. Several future enhancements are planned before turning this on by default. Obviously, the additional checks will be added to MaybeHandleFault. We are also planning to add a two-level CodeObjectData table that is grouped by isolates to make cleanup easier and also reduce potential for contending on a single data structure. BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277 Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Original-Commit-Position: refs/heads/master@{#43523} Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a Review-Url: https://codereview.chromium.org/2371833007 Cr-Original-Commit-Position: refs/heads/master@{#43755} Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b Review-Url: https://codereview.chromium.org/2371833007 Cr-Commit-Position: refs/heads/master@{#43759}
2017-03-13 22:12:23 +00:00
}
} else if (v8_current_cpu == "arm") {
sources += [
### gcmole(arm) ###
"src/codegen/arm/assembler-arm.cc",
"src/codegen/arm/constants-arm.cc",
"src/codegen/arm/cpu-arm.cc",
"src/codegen/arm/macro-assembler-arm.cc",
"src/compiler/backend/arm/code-generator-arm.cc",
"src/compiler/backend/arm/instruction-scheduler-arm.cc",
"src/compiler/backend/arm/instruction-selector-arm.cc",
"src/compiler/backend/arm/unwinding-info-writer-arm.cc",
"src/deoptimizer/arm/deoptimizer-arm.cc",
"src/diagnostics/arm/disasm-arm.cc",
"src/diagnostics/arm/eh-frame-arm.cc",
"src/diagnostics/arm/unwinder-arm.cc",
"src/execution/arm/frame-constants-arm.cc",
"src/execution/arm/simulator-arm.cc",
"src/regexp/arm/regexp-macro-assembler-arm.cc",
]
} else if (v8_current_cpu == "arm64") {
sources += [
### gcmole(arm64) ###
"src/codegen/arm64/assembler-arm64.cc",
"src/codegen/arm64/cpu-arm64.cc",
"src/codegen/arm64/decoder-arm64.cc",
"src/codegen/arm64/instructions-arm64-constants.cc",
"src/codegen/arm64/instructions-arm64.cc",
"src/codegen/arm64/macro-assembler-arm64.cc",
"src/codegen/arm64/register-arm64.cc",
"src/codegen/arm64/utils-arm64.cc",
"src/compiler/backend/arm64/code-generator-arm64.cc",
"src/compiler/backend/arm64/instruction-scheduler-arm64.cc",
"src/compiler/backend/arm64/instruction-selector-arm64.cc",
"src/compiler/backend/arm64/unwinding-info-writer-arm64.cc",
"src/deoptimizer/arm64/deoptimizer-arm64.cc",
"src/diagnostics/arm64/disasm-arm64.cc",
"src/diagnostics/arm64/eh-frame-arm64.cc",
"src/diagnostics/arm64/unwinder-arm64.cc",
"src/execution/arm64/frame-constants-arm64.cc",
"src/execution/arm64/pointer-auth-arm64.cc",
"src/execution/arm64/simulator-arm64.cc",
"src/execution/arm64/simulator-logic-arm64.cc",
"src/regexp/arm64/regexp-macro-assembler-arm64.cc",
]
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
if (v8_enable_webassembly) {
# Trap handling is enabled on arm64 Mac and in simulators on x64 on Linux,
# Mac, and Windows.
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
if ((current_cpu == "arm64" && is_mac) ||
(current_cpu == "x64" && (is_linux || is_chromeos || is_mac))) {
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
sources += [
"src/trap-handler/handler-inside-posix.cc",
"src/trap-handler/handler-outside-posix.cc",
]
} else if (current_cpu == "x64" && is_win) {
sources += [
"src/trap-handler/handler-inside-win.cc",
"src/trap-handler/handler-outside-win.cc",
]
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
}
if (current_cpu == "x64" &&
(is_linux || is_chromeos || is_mac || is_win)) {
Reland "[traphandler] Add simulator support" This is a reland of 431fff66f5db7cdd9a9b25f1d1a5548c188d4e1a. The fix is in BUILD.gn: We need to also include chromeos, which is a linux target which is not covered by "is_linux" in gn. R=ahaas@chromium.org Original change's description: > [traphandler] Add simulator support > > This prepares the trap handler to support being used from simulators. > Modifications to the arm64 simulator will be done in a follow-up CL. For > now, the trap handler will be registered but not used in Wasm (we emit > explicit bounds checks instead, as before). > > The implementation uses inline assembly, so it is only available on x64 > POSIX systems for now. This is the main platform we use for testing and > for fuzzing, so it should give us the test coverage we need. If needed, > inline assembly for other platforms can be added later. > The new code will be executed by the existing arm64 simulator bots, e.g. > "V8 Linux - arm64 - sim". > > R=ahaas@chromium.org, mseaborn@chromium.org > > Bug: v8:11955 > Change-Id: Idc50291c704d9dea902ae0098e5309f19055816c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3011160 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75780} Bug: v8:11955 Change-Id: I8af39dea5b2cd3fa5418170a458832b3d6075107 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3040844 Commit-Queue: Clemens Backes <clemensb@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#75809}
2021-07-20 09:37:56 +00:00
sources += [ "src/trap-handler/handler-outside-simulator.cc" ]
}
}
Unwind V8 frames correctly on Windows ARM64 On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
2019-07-27 06:36:52 +00:00
if (is_win) {
sources += [ "src/diagnostics/unwinding-info-win64.cc" ]
Unwind V8 frames correctly on Windows ARM64 On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
2019-07-27 06:36:52 +00:00
}
} else if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
sources += [
### gcmole(mips64el) ###
"src/codegen/mips64/assembler-mips64.cc",
"src/codegen/mips64/constants-mips64.cc",
"src/codegen/mips64/cpu-mips64.cc",
"src/codegen/mips64/interface-descriptors-mips64-inl.h",
"src/codegen/mips64/macro-assembler-mips64.cc",
"src/compiler/backend/mips64/code-generator-mips64.cc",
"src/compiler/backend/mips64/instruction-scheduler-mips64.cc",
"src/compiler/backend/mips64/instruction-selector-mips64.cc",
"src/deoptimizer/mips64/deoptimizer-mips64.cc",
"src/diagnostics/mips64/disasm-mips64.cc",
"src/diagnostics/mips64/unwinder-mips64.cc",
"src/execution/mips64/frame-constants-mips64.cc",
"src/execution/mips64/simulator-mips64.cc",
"src/regexp/mips64/regexp-macro-assembler-mips64.cc",
]
} else if (v8_current_cpu == "loong64") {
sources += [
### gcmole(loong64) ###
"src/codegen/loong64/assembler-loong64.cc",
"src/codegen/loong64/constants-loong64.cc",
"src/codegen/loong64/cpu-loong64.cc",
"src/codegen/loong64/interface-descriptors-loong64-inl.h",
"src/codegen/loong64/macro-assembler-loong64.cc",
"src/compiler/backend/loong64/code-generator-loong64.cc",
"src/compiler/backend/loong64/instruction-scheduler-loong64.cc",
"src/compiler/backend/loong64/instruction-selector-loong64.cc",
"src/deoptimizer/loong64/deoptimizer-loong64.cc",
"src/diagnostics/loong64/disasm-loong64.cc",
"src/diagnostics/loong64/unwinder-loong64.cc",
"src/execution/loong64/frame-constants-loong64.cc",
"src/execution/loong64/simulator-loong64.cc",
"src/regexp/loong64/regexp-macro-assembler-loong64.cc",
]
} else if (v8_current_cpu == "ppc") {
sources += [
### gcmole(ppc) ###
"src/codegen/ppc/assembler-ppc.cc",
"src/codegen/ppc/constants-ppc.cc",
"src/codegen/ppc/cpu-ppc.cc",
"src/codegen/ppc/macro-assembler-ppc.cc",
"src/compiler/backend/ppc/code-generator-ppc.cc",
"src/compiler/backend/ppc/instruction-scheduler-ppc.cc",
"src/compiler/backend/ppc/instruction-selector-ppc.cc",
"src/compiler/backend/ppc/unwinding-info-writer-ppc.cc",
"src/deoptimizer/ppc/deoptimizer-ppc.cc",
"src/diagnostics/ppc/disasm-ppc.cc",
"src/diagnostics/ppc/eh-frame-ppc.cc",
"src/diagnostics/ppc/unwinder-ppc.cc",
"src/execution/ppc/frame-constants-ppc.cc",
"src/execution/ppc/simulator-ppc.cc",
"src/regexp/ppc/regexp-macro-assembler-ppc.cc",
]
} else if (v8_current_cpu == "ppc64") {
sources += [
### gcmole(ppc64) ###
"src/codegen/ppc/assembler-ppc.cc",
"src/codegen/ppc/constants-ppc.cc",
"src/codegen/ppc/cpu-ppc.cc",
"src/codegen/ppc/macro-assembler-ppc.cc",
"src/compiler/backend/ppc/code-generator-ppc.cc",
"src/compiler/backend/ppc/instruction-scheduler-ppc.cc",
"src/compiler/backend/ppc/instruction-selector-ppc.cc",
"src/compiler/backend/ppc/unwinding-info-writer-ppc.cc",
"src/deoptimizer/ppc/deoptimizer-ppc.cc",
"src/diagnostics/ppc/disasm-ppc.cc",
"src/diagnostics/ppc/eh-frame-ppc.cc",
"src/diagnostics/ppc/unwinder-ppc.cc",
"src/execution/ppc/frame-constants-ppc.cc",
"src/execution/ppc/simulator-ppc.cc",
"src/regexp/ppc/regexp-macro-assembler-ppc.cc",
]
} else if (v8_current_cpu == "s390" || v8_current_cpu == "s390x") {
sources += [
### gcmole(s390) ###
"src/codegen/s390/assembler-s390.cc",
"src/codegen/s390/constants-s390.cc",
"src/codegen/s390/cpu-s390.cc",
"src/codegen/s390/macro-assembler-s390.cc",
"src/compiler/backend/s390/code-generator-s390.cc",
"src/compiler/backend/s390/instruction-scheduler-s390.cc",
"src/compiler/backend/s390/instruction-selector-s390.cc",
"src/compiler/backend/s390/unwinding-info-writer-s390.cc",
"src/deoptimizer/s390/deoptimizer-s390.cc",
"src/diagnostics/s390/disasm-s390.cc",
"src/diagnostics/s390/eh-frame-s390.cc",
"src/diagnostics/s390/unwinder-s390.cc",
"src/execution/s390/frame-constants-s390.cc",
"src/execution/s390/simulator-s390.cc",
"src/regexp/s390/regexp-macro-assembler-s390.cc",
]
} else if (v8_current_cpu == "riscv64") {
sources += [
### gcmole(riscv64) ###
"src/codegen/riscv/assembler-riscv.cc",
"src/codegen/riscv/base-assembler-riscv.cc",
"src/codegen/riscv/base-constants-riscv.cc",
"src/codegen/riscv/base-riscv-i.cc",
"src/codegen/riscv/cpu-riscv.cc",
"src/codegen/riscv/extension-riscv-a.cc",
"src/codegen/riscv/extension-riscv-c.cc",
"src/codegen/riscv/extension-riscv-d.cc",
"src/codegen/riscv/extension-riscv-f.cc",
"src/codegen/riscv/extension-riscv-m.cc",
"src/codegen/riscv/extension-riscv-v.cc",
"src/codegen/riscv/extension-riscv-zicsr.cc",
"src/codegen/riscv/extension-riscv-zifencei.cc",
"src/codegen/riscv/macro-assembler-riscv.cc",
"src/compiler/backend/riscv/code-generator-riscv.cc",
"src/compiler/backend/riscv/instruction-scheduler-riscv.cc",
"src/compiler/backend/riscv/instruction-selector-riscv64.cc",
"src/deoptimizer/riscv/deoptimizer-riscv.cc",
"src/diagnostics/riscv/disasm-riscv.cc",
"src/diagnostics/riscv/unwinder-riscv.cc",
"src/execution/riscv/frame-constants-riscv.cc",
"src/execution/riscv/simulator-riscv.cc",
"src/regexp/riscv/regexp-macro-assembler-riscv.cc",
]
} else if (v8_current_cpu == "riscv32") {
sources += [
### gcmole(riscv32) ###
"src/codegen/riscv/assembler-riscv.cc",
"src/codegen/riscv/base-assembler-riscv.cc",
"src/codegen/riscv/base-constants-riscv.cc",
"src/codegen/riscv/base-riscv-i.cc",
"src/codegen/riscv/cpu-riscv.cc",
"src/codegen/riscv/extension-riscv-a.cc",
"src/codegen/riscv/extension-riscv-c.cc",
"src/codegen/riscv/extension-riscv-d.cc",
"src/codegen/riscv/extension-riscv-f.cc",
"src/codegen/riscv/extension-riscv-m.cc",
"src/codegen/riscv/extension-riscv-v.cc",
"src/codegen/riscv/extension-riscv-zicsr.cc",
"src/codegen/riscv/extension-riscv-zifencei.cc",
"src/codegen/riscv/macro-assembler-riscv.cc",
"src/compiler/backend/riscv/code-generator-riscv.cc",
"src/compiler/backend/riscv/instruction-scheduler-riscv.cc",
"src/compiler/backend/riscv/instruction-selector-riscv32.cc",
"src/deoptimizer/riscv/deoptimizer-riscv.cc",
"src/diagnostics/riscv/disasm-riscv.cc",
"src/diagnostics/riscv/unwinder-riscv.cc",
"src/execution/riscv/frame-constants-riscv.cc",
"src/execution/riscv/simulator-riscv.cc",
"src/regexp/riscv/regexp-macro-assembler-riscv.cc",
]
}
# Architecture independent but platform-specific sources
if (is_win) {
if (v8_enable_etw_stack_walking) {
sources += [
"src/diagnostics/etw-jit-win.cc",
"src/diagnostics/etw-jit-win.h",
]
}
}
configs = [
":internal_config",
":cppgc_base_config",
]
deps = [
":torque_generated_definitions",
":v8_bigint",
":v8_headers",
":v8_heap_base",
":v8_libbase",
":v8_shared_internal_headers",
":v8_tracing",
":v8_version",
Revert "[build] Separate out inspector as a shared library" This reverts commit 92bfb63cace73b967644abb6a26e8703350a7507. Reason for revert: Broke build https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/43249/overview Original change's description: > [build] Separate out inspector as a shared library > > This makes src/inspector:inspector into a v8_component producing a > shared library in component builds. To enable this, all of its exported > are now marked with V8_INSPECTOR_EXPORT. > > This also inverts the dependency between src/inspector:inspector and > :v8_base_without_compiler, and instead makes d8 and some tests depend on > inspector rather than getting it via v8. > > As a result, the no_check_targets exclusions list in .gn is reduced. > > Ultimately embedders like chromium should depend on :v8 and optionally > src/inspector:inspector, but to allow that transition to occur, this > renames :v8 to :v8_lib and introduces a new :v8 which depends on v8 and > inspector. Once all embedders have changed to reflect the new structure, > this part can be reverted. > > Bug: v8:11917 > Change-Id: Ia8b15f07fb15acc5e1f111b1a80248def4285fd0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999088 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75532} Bug: v8:11917 Change-Id: I0ed27ed95211d13b8b3438a8c0a42d577806c475 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003452 Auto-Submit: Zhi An Ng <zhin@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75533}
2021-07-02 16:14:44 +00:00
"src/inspector:inspector",
]
public_deps = [
":cppgc_base",
":generate_bytecode_builtins_list",
":run_torque",
":v8_headers",
":v8_internal_headers",
":v8_maybe_icu",
]
if (v8_enable_i18n_support) {
deps += [ ":run_gen-regexp-special-case" ]
sources += [ "$target_gen_dir/src/regexp/special-case.cc" ]
if (is_win) {
deps += [ "//third_party/icu:icudata" ]
}
} else {
sources -= [
"src/builtins/builtins-intl.cc",
"src/objects/intl-objects.cc",
"src/objects/js-break-iterator.cc",
"src/objects/js-collator.cc",
"src/objects/js-date-time-format.cc",
"src/objects/js-display-names.cc",
"src/objects/js-duration-format.cc",
"src/objects/js-list-format.cc",
"src/objects/js-locale.cc",
"src/objects/js-number-format.cc",
"src/objects/js-plural-rules.cc",
"src/objects/js-relative-time-format.cc",
"src/objects/js-segment-iterator.cc",
"src/objects/js-segmenter.cc",
"src/objects/js-segments.cc",
"src/runtime/runtime-intl.cc",
"src/strings/char-predicates.cc",
]
}
if (v8_use_zlib) {
deps += [
"//third_party/zlib",
"//third_party/zlib/google:compression_utils_portable",
]
}
if (v8_postmortem_support) {
sources += [ "$target_gen_dir/debug-support.cc" ]
deps += [ ":postmortem-metadata" ]
}
libs = []
if (v8_enable_third_party_heap) {
libs += v8_third_party_heap_libs
}
# Platforms that don't have CAS support need to link atomic library
# to implement atomic memory access
if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el" ||
v8_current_cpu == "ppc" || v8_current_cpu == "ppc64" ||
v8_current_cpu == "s390" || v8_current_cpu == "s390x" ||
v8_current_cpu == "riscv64" || v8_current_cpu == "riscv32") {
libs += [ "atomic" ]
}
Reland "Support Intel VTune ITT API" This is a reland of 5f5b4b04078a5da96b4c8244241cf73dc928f721 Original change's description: > Support Intel VTune ITT API > > Add VTune domain support extension to use VTune Domain/Task API and > tagging trace data for particular JS code block. > > How to use: > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient > file to download intel/ittapi by 'gclient sync' > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true' > 3. Run d8 with flag '--enable-vtune-domain-support' > > The Vtune Domain/Task API can be invoked from JS to mark JS code block. > You can mark the start of a JS task by > vtunedomainmark(domain_name, task_name, "start") > and the end of a task by > vtunedomainmark(domain_name, task_name, "end") > Tasks can nest. > > The VTune API (ittapi) is integrated as an external third party library > while the v8_vtune_jit also relies on the VTune ittapi. We have another > patch almost ready which refactors the v8_vtune_jit related code to > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit > code after this patch stabilized and landed. > > > Contributed by fanchen.kong@intel.com > > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490 > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65409} Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65478}
2019-12-14 08:46:38 +00:00
if (v8_enable_vtunetracemark && (is_linux || is_chromeos || is_win)) {
Reland "Support Intel VTune ITT API" This is a reland of 5f5b4b04078a5da96b4c8244241cf73dc928f721 Original change's description: > Support Intel VTune ITT API > > Add VTune domain support extension to use VTune Domain/Task API and > tagging trace data for particular JS code block. > > How to use: > 1. Set `"checkout_ittapi" = True` in the custom_vars section of .gclient > file to download intel/ittapi by 'gclient sync' > 2. Build d8 with gn build flag 'v8_enable_vtunetracemark = true' > 3. Run d8 with flag '--enable-vtune-domain-support' > > The Vtune Domain/Task API can be invoked from JS to mark JS code block. > You can mark the start of a JS task by > vtunedomainmark(domain_name, task_name, "start") > and the end of a task by > vtunedomainmark(domain_name, task_name, "end") > Tasks can nest. > > The VTune API (ittapi) is integrated as an external third party library > while the v8_vtune_jit also relies on the VTune ittapi. We have another > patch almost ready which refactors the v8_vtune_jit related code to > depend on the third_party/ittapi. We will submit the refactored v8_vtune_jit > code after this patch stabilized and landed. > > > Contributed by fanchen.kong@intel.com > > Change-Id: I0ecc9dd4e1ea52545f1b6932fcdadfa7c1a6d2b2 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1938490 > Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#65409} Change-Id: I563aa70fa2b8abe34c981af47aa7220cfc2a7edb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1963511 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#65478}
2019-12-14 08:46:38 +00:00
sources += [
"src/extensions/vtunedomain-support-extension.cc",
"src/extensions/vtunedomain-support-extension.h",
]
deps += [ "src/third_party/vtune:v8_vtune_trace_mark" ]
}
if (v8_use_perfetto) {
sources += [
"src/tracing/trace-categories.cc",
"src/tracing/trace-categories.h",
]
}
}
group("v8_base") {
public_deps = [
":v8_base_without_compiler",
":v8_compiler",
":v8_turboshaft",
]
}
v8_source_set("torque_base") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [
"src/numbers/integer-literal-inl.h",
"src/numbers/integer-literal.h",
"src/torque/ast.h",
"src/torque/cc-generator.cc",
"src/torque/cc-generator.h",
"src/torque/cfg.cc",
"src/torque/cfg.h",
Reland "Add postmortem debugging helper library" This is a reland of 517ab73fd7e3fdb70220b9699bca4c69a32e212e Updates since original: now compressed pointers passed to the function GetObjectProperties are required to be sign-extended. Previously, the function allowed zero-extended values, but that led to ambiguity on pointers like 0x88044919: is it compressed or is the heap range actually centered on 0x100000000? Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} Bug: v8:9376 Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
2019-07-30 14:38:15 +00:00
"src/torque/class-debug-reader-generator.cc",
"src/torque/constants.h",
"src/torque/contextual.h",
"src/torque/cpp-builder.cc",
"src/torque/cpp-builder.h",
"src/torque/csa-generator.cc",
"src/torque/csa-generator.h",
"src/torque/declarable.cc",
"src/torque/declarable.h",
"src/torque/declaration-visitor.cc",
"src/torque/declaration-visitor.h",
"src/torque/declarations.cc",
"src/torque/declarations.h",
"src/torque/earley-parser.cc",
"src/torque/earley-parser.h",
"src/torque/global-context.cc",
"src/torque/global-context.h",
"src/torque/implementation-visitor.cc",
"src/torque/implementation-visitor.h",
[torque] Generate instance types Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
2019-10-11 21:52:06 +00:00
"src/torque/instance-type-generator.cc",
"src/torque/instructions.cc",
"src/torque/instructions.h",
"src/torque/kythe-data.cc",
"src/torque/kythe-data.h",
"src/torque/parameter-difference.h",
"src/torque/server-data.cc",
"src/torque/server-data.h",
"src/torque/source-positions.cc",
"src/torque/source-positions.h",
"src/torque/torque-code-generator.cc",
"src/torque/torque-code-generator.h",
"src/torque/torque-compiler.cc",
"src/torque/torque-compiler.h",
"src/torque/torque-parser.cc",
"src/torque/torque-parser.h",
"src/torque/type-inference.cc",
"src/torque/type-inference.h",
"src/torque/type-oracle.cc",
"src/torque/type-oracle.h",
"src/torque/type-visitor.cc",
"src/torque/type-visitor.h",
"src/torque/types.cc",
"src/torque/types.h",
"src/torque/utils.cc",
"src/torque/utils.h",
]
deps = [
":v8_flags",
":v8_shared_internal_headers",
]
Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of 251d1623f34fba74fb84262914946840c5cd629c The reland fixes ASAN component builds by adding RTTI build config to both torque executables. Big thanks to sigurds for finding the fix. Original change's description: > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > The issue on the windows bot is apparently a compiler bug in MSVC related to > move construction. The fix seems to be to change the order of the fields in > "JsonParseResult" (go figure). > > Drive-by-change: Fix LS on windows by emitting correct line endings and > enabling exceptions for the LS executable as well. > > Original change's description: > > [torque] Throw exception instead of aborting if something goes wrong > > > > This CL enables exceptions for the Torque compiler and Torque language > > server. Instead of aborting when something goes wrong during > > compilation, a TorqueError is thrown, containing the error message > > and a source position. The compiler executable still prints the error > > and aborts, while the language server will pass this information > > along to the client (not included in this CL). > > > > R=danno@chromium.org > > > > Bug: v8:8880 > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60512} > > Bug: v8:8880 > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60736} Bug: v8:8880 Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60804}
2019-04-12 04:06:41 +00:00
public_deps = [ ":v8_libbase" ]
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
# The use of exceptions for Torque in violation of the Chromium style-guide
# is justified by the fact that it is only used from the non-essential
# language server and can be removed anytime if it causes problems.
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
configs = [
":internal_config",
"//build/config/compiler:exceptions",
"//build/config/compiler:rtti",
]
remove_configs = [
"//build/config/compiler:no_exceptions",
"//build/config/compiler:no_rtti",
]
if (is_win && is_asan) {
# Due to a bug in ASAN on Windows (chromium:893437), we disable ASAN for
# Torque on Windows.
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
remove_configs += [ "//build/config/sanitizers:default_sanitizer_flags" ]
}
if (is_debug && !v8_optimized_debug && v8_enable_fast_torque) {
# The :no_optimize config is added to v8_add_configs in v8.gni.
remove_configs += [ "//build/config/compiler:no_optimize" ]
configs += [ ":always_turbofanimize" ]
}
}
v8_source_set("torque_ls_base") {
sources = [
"src/torque/ls/globals.h",
"src/torque/ls/json-parser.cc",
"src/torque/ls/json-parser.h",
"src/torque/ls/json.cc",
"src/torque/ls/json.h",
"src/torque/ls/message-handler.cc",
"src/torque/ls/message-handler.h",
"src/torque/ls/message-macros.h",
"src/torque/ls/message-pipe.h",
"src/torque/ls/message.h",
]
public_deps = [ ":torque_base" ]
# The use of exceptions for Torque in violation of the Chromium style-guide
# is justified by the fact that it is only used from the non-essential
# language server and can be removed anytime if it causes problems.
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
configs = [
":internal_config",
"//build/config/compiler:exceptions",
"//build/config/compiler:rtti",
]
remove_configs = [
"//build/config/compiler:no_exceptions",
"//build/config/compiler:no_rtti",
]
if (is_win && is_asan) {
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
remove_configs += [ "//build/config/sanitizers:default_sanitizer_flags" ]
}
}
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
v8_component("v8_libbase") {
sources = [
"src/base/address-region.h",
"src/base/atomic-utils.h",
"src/base/atomicops.h",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
"src/base/base-export.h",
"src/base/bit-field.h",
"src/base/bits-iterator.h",
"src/base/bits.cc",
"src/base/bits.h",
"src/base/bounded-page-allocator.cc",
"src/base/bounded-page-allocator.h",
"src/base/bounds.h",
"src/base/build_config.h",
"src/base/compiler-specific.h",
"src/base/container-utils.h",
"src/base/cpu.cc",
"src/base/cpu.h",
"src/base/debug/stack_trace.cc",
"src/base/debug/stack_trace.h",
"src/base/division-by-constant.cc",
"src/base/division-by-constant.h",
"src/base/emulated-virtual-address-subspace.cc",
"src/base/emulated-virtual-address-subspace.h",
"src/base/enum-set.h",
"src/base/export-template.h",
"src/base/file-utils.cc",
"src/base/file-utils.h",
"src/base/flags.h",
"src/base/free_deleter.h",
"src/base/functional.h",
"src/base/hashmap-entry.h",
"src/base/hashmap.h",
"src/base/ieee754.cc",
"src/base/ieee754.h",
"src/base/immediate-crash.h",
"src/base/iterator.h",
"src/base/lazy-instance.h",
"src/base/logging.cc",
"src/base/logging.h",
"src/base/macros.h",
"src/base/memory.h",
"src/base/numbers/bignum-dtoa.cc",
"src/base/numbers/bignum-dtoa.h",
"src/base/numbers/bignum.cc",
"src/base/numbers/bignum.h",
"src/base/numbers/cached-powers.cc",
"src/base/numbers/cached-powers.h",
"src/base/numbers/diy-fp.cc",
"src/base/numbers/diy-fp.h",
"src/base/numbers/double.h",
"src/base/numbers/dtoa.cc",
"src/base/numbers/dtoa.h",
"src/base/numbers/fast-dtoa.cc",
"src/base/numbers/fast-dtoa.h",
"src/base/numbers/fixed-dtoa.cc",
"src/base/numbers/fixed-dtoa.h",
"src/base/numbers/strtod.cc",
"src/base/numbers/strtod.h",
"src/base/once.cc",
"src/base/once.h",
"src/base/optional.h",
"src/base/overflowing-math.h",
"src/base/page-allocator.cc",
"src/base/page-allocator.h",
"src/base/platform/condition-variable.cc",
"src/base/platform/condition-variable.h",
"src/base/platform/elapsed-timer.h",
"src/base/platform/memory-protection-key.cc",
"src/base/platform/memory-protection-key.h",
"src/base/platform/memory.h",
"src/base/platform/mutex.cc",
"src/base/platform/mutex.h",
"src/base/platform/platform.h",
"src/base/platform/semaphore.cc",
"src/base/platform/semaphore.h",
"src/base/platform/time.cc",
"src/base/platform/time.h",
"src/base/platform/wrappers.h",
"src/base/platform/yield-processor.h",
"src/base/pointer-with-payload.h",
"src/base/region-allocator.cc",
"src/base/region-allocator.h",
"src/base/ring-buffer.h",
"src/base/safe_conversions.h",
"src/base/safe_conversions_arm_impl.h",
"src/base/safe_conversions_impl.h",
"src/base/sanitizer/asan.h",
"src/base/sanitizer/lsan-page-allocator.cc",
"src/base/sanitizer/lsan-page-allocator.h",
"src/base/sanitizer/lsan-virtual-address-space.cc",
"src/base/sanitizer/lsan-virtual-address-space.h",
"src/base/sanitizer/lsan.h",
"src/base/sanitizer/msan.h",
"src/base/sanitizer/tsan.h",
"src/base/small-vector.h",
"src/base/string-format.h",
"src/base/strings.cc",
"src/base/strings.h",
"src/base/sys-info.cc",
"src/base/sys-info.h",
"src/base/template-utils.h",
"src/base/threaded-list.h",
"src/base/timezone-cache.h",
"src/base/utils/random-number-generator.cc",
"src/base/utils/random-number-generator.h",
"src/base/v8-fallthrough.h",
"src/base/vector.h",
"src/base/virtual-address-space-page-allocator.cc",
"src/base/virtual-address-space-page-allocator.h",
"src/base/virtual-address-space.cc",
"src/base/virtual-address-space.h",
"src/base/vlq-base64.cc",
"src/base/vlq-base64.h",
"src/base/vlq.h",
]
configs = [ ":internal_config_base" ]
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
public_configs = [ ":libbase_config" ]
deps = [ ":v8_config_headers" ]
data = []
data_deps = []
defines = []
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
if (is_component_build) {
defines = [ "BUILDING_V8_BASE_SHARED" ]
}
if (is_posix || is_fuchsia) {
sources += [
"src/base/platform/platform-posix.cc",
"src/base/platform/platform-posix.h",
]
if (current_os != "aix") {
sources += [
"src/base/platform/platform-posix-time.cc",
"src/base/platform/platform-posix-time.h",
]
}
}
if (is_linux || is_chromeos) {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-linux.cc",
"src/base/platform/platform-linux.h",
]
libs = [
"dl",
"rt",
]
} else if (current_os == "aix") {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-aix.cc",
]
libs = [ "dl" ]
} else if (is_android) {
if (current_toolchain == host_toolchain) {
libs = [
"dl",
"rt",
]
if (host_os == "mac") {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-darwin.cc",
"src/base/platform/platform-macos.cc",
]
} else {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-linux.cc",
]
}
} else {
sources += [
"src/base/debug/stack_trace_android.cc",
"src/base/platform/platform-linux.cc",
]
}
} else if (is_fuchsia) {
sources += [
"src/base/debug/stack_trace_fuchsia.cc",
"src/base/platform/platform-fuchsia.cc",
]
deps += [
"//third_party/fuchsia-sdk/sdk/fidl/fuchsia.kernel",
"//third_party/fuchsia-sdk/sdk/pkg/fdio",
"//third_party/fuchsia-sdk/sdk/pkg/zx",
]
} else if (is_mac) {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-darwin.cc",
"src/base/platform/platform-macos.cc",
]
} else if (is_ios) {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-darwin.cc",
]
} else if (is_win) {
# TODO(infra): Add support for cygwin.
sources += [
"src/base/debug/stack_trace_win.cc",
"src/base/platform/platform-win32.cc",
"src/base/win32-headers.h",
]
defines += [ "_CRT_RAND_S" ] # for rand_s()
libs = [
"dbghelp.lib",
"winmm.lib",
"ws2_32.lib",
]
if (v8_enable_etw_stack_walking) {
Step 1 (of 3-ish): Basic ETW Instrumentation in V8 Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
2021-01-05 18:43:34 +00:00
libs += [ "advapi32.lib" ] # Needed for TraceLoggingProvider.h
}
data_deps += [ "//build/win:runtime_libs" ]
}
if (v8_current_cpu == "mips64") {
# Add runtime libs for mips.
data += [
"tools/mips_toolchain/sysroot/usr/lib/",
"tools/mips_toolchain/mips-mti-linux-gnu/lib",
]
}
if (is_ubsan && (v8_current_cpu == "x86" || v8_current_cpu == "arm")) {
# Special UBSan 32-bit requirement.
sources += [ "src/base/ubsan.cc" ]
}
if (v8_current_cpu == "riscv64" || v8_current_cpu == "riscv32") {
libs += [ "atomic" ]
}
if (is_tsan && !build_with_chromium) {
data += [ "tools/sanitizers/tsan_suppressions.txt" ]
}
if (using_sanitizer && !build_with_chromium) {
data_deps +=
[ "//build/config/clang:llvm-symbolizer_data($host_toolchain)" ]
}
if (v8_use_libm_trig_functions) {
deps += [ ":libm" ]
}
# TODO(infra): Add support for qnx, freebsd, openbsd, netbsd, and solaris.
}
if (v8_use_libm_trig_functions) {
source_set("libm") {
sources = [
"third_party/glibc/src/sysdeps/ieee754/dbl-64/branred.c",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/branred.h",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/dla.h",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/endian.h",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/mydefs.h",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/s_sin.c",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/sincostab.c",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/trig.h",
"third_party/glibc/src/sysdeps/ieee754/dbl-64/usncs.h",
]
configs += [ "//build/config/compiler:no_chromium_code" ]
configs -= [ "//build/config/compiler:chromium_code" ]
if (!is_debug) {
# Build code using -O3, see: crbug.com/1084371.
configs += [ "//build/config/compiler:optimize_speed" ]
}
}
}
v8_component("v8_libplatform") {
sources = [
"//base/trace_event/common/trace_event_common.h",
"include/libplatform/libplatform-export.h",
"include/libplatform/libplatform.h",
"include/libplatform/v8-tracing.h",
Reland "[platform] Implement TaskRunners in the DefaultPlatform" There was a data race in the access of the foreground_task_runner_map_. I protect each access to foreground_task_runner_map_ with a lock now. Original change's description: > [platform] Implement TaskRunners in the DefaultPlatform > > This CL implements the TaskRunners in the DefaultPlatform which has been > added recently to the platform API. In addition I changed how task > posting works on the DefaultPlatform. > > With this implementation the DefaultPlatform keeps one > DefaultForegroundTaskRunner per isolate, plus one > DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners > with a shared_ptr, which is also shared with any caller of > GetForegroundTaskRunner or GetBackgroundTaskrunner. > > This CL moves the task management from the DefaultPlatform to the > TaskRunners. The DefaultForegroundTaskRunner owns and manages the the > task queue, the delayed task queue, and the idle task queue. The > DefaultBackgroundTaskRunner owns the WorkerThread pool and the > background task queue. > > In addition changed many Task* to std::unique_ptr<Task> to document task > ownership. > > R=rmcilroy@chromium.org > > Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27 > Reviewed-on: https://chromium-review.googlesource.com/753583 > Commit-Queue: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49354} Change-Id: Iddccdb07bde1a799815ec6ed6af37082df4987c7 Reviewed-on: https://chromium-review.googlesource.com/770970 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#49379}
2017-11-15 12:07:22 +00:00
"src/libplatform/default-foreground-task-runner.cc",
"src/libplatform/default-foreground-task-runner.h",
"src/libplatform/default-job.cc",
"src/libplatform/default-job.h",
"src/libplatform/default-platform.cc",
"src/libplatform/default-platform.h",
"src/libplatform/default-worker-threads-task-runner.cc",
"src/libplatform/default-worker-threads-task-runner.h",
"src/libplatform/delayed-task-queue.cc",
"src/libplatform/delayed-task-queue.h",
"src/libplatform/task-queue.cc",
"src/libplatform/task-queue.h",
"src/libplatform/tracing/trace-buffer.cc",
"src/libplatform/tracing/trace-buffer.h",
"src/libplatform/tracing/trace-config.cc",
"src/libplatform/tracing/trace-object.cc",
"src/libplatform/tracing/trace-writer.cc",
"src/libplatform/tracing/trace-writer.h",
"src/libplatform/tracing/tracing-controller.cc",
"src/libplatform/worker-thread.cc",
"src/libplatform/worker-thread.h",
]
configs = [ ":internal_config_base" ]
if (is_component_build) {
defines = [ "BUILDING_V8_PLATFORM_SHARED" ]
}
public_configs = [ ":libplatform_config" ]
public_deps = []
deps = [
":v8_config_headers",
":v8_libbase",
":v8_tracing",
]
if (v8_use_perfetto) {
sources -= [
"//base/trace_event/common/trace_event_common.h",
"src/libplatform/tracing/trace-buffer.cc",
"src/libplatform/tracing/trace-buffer.h",
"src/libplatform/tracing/trace-object.cc",
"src/libplatform/tracing/trace-writer.cc",
"src/libplatform/tracing/trace-writer.h",
]
sources += [
"src/libplatform/tracing/trace-event-listener.cc",
[tracing] Add a way to test perfetto traces. Add a new abstract class TraceEventListener which is just an interface for consuming trace events. This separates the V8-specific stuff that an actual perfetto consumer needs to do e.g. handling the has_more flag and signalling back to the controller with a semaphore. This is a change from the previous plan of making the PerfettoConsumer class sub-classable to implement custom consumption of trace events. This will be difficult when the consumer is created outside of the PerfettoTracingController as we can't hook up the consumer_finished_semaphore_ that belongs to the controller. Now the PerfettoTracingController is responsible for the Consumer life- cycle and hides it entirely from callers. We add the AddTraceEventListener() method to allow callers to register a listener either for testing or a JSON listener for real tracing. This lets us write tests that can store all the trace events in memory without first converting them to JSON, letting us write test more easily. There's an example test add to test-tracing - more tests using this style will follow. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: I2d2b0f408b1c7bed954144163e1968f40d772c1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628789 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61854}
2019-05-27 12:46:35 +00:00
"src/libplatform/tracing/trace-event-listener.h",
]
deps += [
# TODO(skyostil): Switch TraceEventListener to protozero.
"//third_party/perfetto/protos/perfetto/trace:lite",
]
}
if (v8_enable_system_instrumentation) {
sources += [ "src/libplatform/tracing/recorder.h" ]
if (is_mac) {
sources += [ "src/libplatform/tracing/recorder-mac.cc" ]
} else if (is_win) {
sources += [ "src/libplatform/tracing/recorder-win.cc" ]
}
}
if (v8_current_cpu == "riscv64" || v8_current_cpu == "riscv32") {
libs = [ "atomic" ]
}
}
v8_source_set("fuzzer_support") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [
"test/fuzzer/fuzzer-support.cc",
"test/fuzzer/fuzzer-support.h",
]
configs = [ ":internal_config_base" ]
public_deps = [
":v8",
":v8_libbase",
":v8_libplatform",
":v8_maybe_icu",
]
}
v8_source_set("v8_bigint") {
sources = [
"src/bigint/bigint-internal.cc",
"src/bigint/bigint-internal.h",
"src/bigint/bigint.h",
"src/bigint/bitwise.cc",
"src/bigint/digit-arithmetic.h",
"src/bigint/div-burnikel.cc",
"src/bigint/div-helpers.cc",
"src/bigint/div-helpers.h",
"src/bigint/div-schoolbook.cc",
"src/bigint/fromstring.cc",
"src/bigint/mul-karatsuba.cc",
"src/bigint/mul-schoolbook.cc",
"src/bigint/tostring.cc",
"src/bigint/util.h",
"src/bigint/vector-arithmetic.cc",
"src/bigint/vector-arithmetic.h",
]
if (v8_advanced_bigint_algorithms) {
sources += [
"src/bigint/div-barrett.cc",
"src/bigint/mul-fft.cc",
"src/bigint/mul-toom.cc",
]
}
configs = [ ":internal_config" ]
}
v8_header_set("v8_heap_base_headers") {
[heap] Improve accounting of PagedSpace::CommittedPhysicalMemory() Instead of using the high water mark for determining this metric, we use a bitset for all active/used system pages on a V8 heap page. Each time when allocating a LAB on a page, we add the pages of that memory range to that bitset. During sweeping we rebuild that bitset from scratch and replace it with the old one in case free pages are discarded by the GC. We DCHECK here that the sweeper only ever removes pages. This has the nice benefit of ensuring that we don't miss any allocations (like we do now for concurrent allocations). CommittedPhysicalMemory for a page is then calculated by counting the set bits in the bitset and multiplying it with the system page size. This should be simpler to verify and track the "real" effective size more precisely. One case where we are partially less precise than the current implementation is for LABs. In order to reduce complexity we now treat all pages of a LAB allocation as active immediately. In the current implementation we tried to only account the actual used part of the LAB when changing the LAB later. This is more complex to track correctly but also doesn't account the currently used LAB in effective size. Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#79428}
2022-03-09 16:49:56 +00:00
sources = [
"src/heap/base/active-system-pages.h",
"src/heap/base/basic-slot-set.h",
[heap] Improve accounting of PagedSpace::CommittedPhysicalMemory() Instead of using the high water mark for determining this metric, we use a bitset for all active/used system pages on a V8 heap page. Each time when allocating a LAB on a page, we add the pages of that memory range to that bitset. During sweeping we rebuild that bitset from scratch and replace it with the old one in case free pages are discarded by the GC. We DCHECK here that the sweeper only ever removes pages. This has the nice benefit of ensuring that we don't miss any allocations (like we do now for concurrent allocations). CommittedPhysicalMemory for a page is then calculated by counting the set bits in the bitset and multiplying it with the system page size. This should be simpler to verify and track the "real" effective size more precisely. One case where we are partially less precise than the current implementation is for LABs. In order to reduce complexity we now treat all pages of a LAB allocation as active immediately. In the current implementation we tried to only account the actual used part of the LAB when changing the LAB later. This is more complex to track correctly but also doesn't account the currently used LAB in effective size. Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#79428}
2022-03-09 16:49:56 +00:00
"src/heap/base/stack.h",
"src/heap/base/worklist.h",
]
configs = [ ":internal_config" ]
public_deps = [ ":v8_libbase" ]
}
v8_source_set("v8_heap_base") {
sources = [
[heap] Improve accounting of PagedSpace::CommittedPhysicalMemory() Instead of using the high water mark for determining this metric, we use a bitset for all active/used system pages on a V8 heap page. Each time when allocating a LAB on a page, we add the pages of that memory range to that bitset. During sweeping we rebuild that bitset from scratch and replace it with the old one in case free pages are discarded by the GC. We DCHECK here that the sweeper only ever removes pages. This has the nice benefit of ensuring that we don't miss any allocations (like we do now for concurrent allocations). CommittedPhysicalMemory for a page is then calculated by counting the set bits in the bitset and multiplying it with the system page size. This should be simpler to verify and track the "real" effective size more precisely. One case where we are partially less precise than the current implementation is for LABs. In order to reduce complexity we now treat all pages of a LAB allocation as active immediately. In the current implementation we tried to only account the actual used part of the LAB when changing the LAB later. This is more complex to track correctly but also doesn't account the currently used LAB in effective size. Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#79428}
2022-03-09 16:49:56 +00:00
"src/heap/base/active-system-pages.cc",
"src/heap/base/stack.cc",
Reland "Reland "cppgc, heap: Don't eagerly allocate worklist segments"" This is a reland of f25cb50a2fc5f51d7bd70e885fb7e6e4123d77dc Removed the problematic tests. The problem with the test was that we try to pop from an empty segment. GCC flags that as accessing beyond the array (i.e. index is uint16_t equivalent of -1). Preceding the actual pop is a DCHECK that asserts the segment isn't empty. In practice, since we have the DCHECK and access to the segment is always via a Local, this shouldn't be a problem. Unfortunately, GCC flags the access regardless. The DCHECK goes through a function pointer so GCC cannot determine that in our unittest the DCHECK would crash if index is 0 and the access would not happen (The indirection was added to allow for test DCHECK handlers that don't crash, so we can't mark the function pointer as noreturn). Drive-by: Segment::Pop and Segment::Push rely on the their Local counterparts checking of emptiness/fullness, so we should always access segments via Locals. Making the Segment ctor private. Original change's description: > Reland "cppgc, heap: Don't eagerly allocate worklist segments" > > This is a reland of c99147c65e31487928574660bebea543249cdf5a > > Original change's description: > > cppgc, heap: Don't eagerly allocate worklist segments > > > > Bug: chromium:1056170 > > Change-Id: I75a6b5f52bfe8dd71abc086e5d1e060759ad7fc0 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2391254 > > Commit-Queue: Omer Katz <omerkatz@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#69778} > > Bug: chromium:1056170 > Change-Id: I4633da065976a6b2710d2f23b946fd2af0e65c83 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401425 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Omer Katz <omerkatz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69806} Bug: chromium:1056170 Change-Id: I7a122d1a2d20cd4e7c824d249975b4d3df30e03e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2403251 Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#69829}
2020-09-10 15:31:31 +00:00
"src/heap/base/worklist.cc",
]
if (is_clang || !is_win) {
if (current_cpu == "x64") {
sources += [ "src/heap/base/asm/x64/save_registers_asm.cc" ]
} else if (current_cpu == "x86") {
sources += [ "src/heap/base/asm/ia32/save_registers_asm.cc" ]
} else if (current_cpu == "arm") {
sources += [ "src/heap/base/asm/arm/save_registers_asm.cc" ]
} else if (current_cpu == "arm64") {
sources += [ "src/heap/base/asm/arm64/save_registers_asm.cc" ]
} else if (current_cpu == "ppc64") {
sources += [ "src/heap/base/asm/ppc/save_registers_asm.cc" ]
} else if (current_cpu == "s390x") {
sources += [ "src/heap/base/asm/s390/save_registers_asm.cc" ]
} else if (current_cpu == "mips64el") {
sources += [ "src/heap/base/asm/mips64/save_registers_asm.cc" ]
} else if (current_cpu == "loong64") {
sources += [ "src/heap/base/asm/loong64/save_registers_asm.cc" ]
} else if (current_cpu == "riscv64" || current_cpu == "riscv32") {
sources += [ "src/heap/base/asm/riscv/save_registers_asm.cc" ]
}
} else if (is_win) {
if (current_cpu == "x64") {
sources += [ "src/heap/base/asm/x64/save_registers_masm.asm" ]
} else if (current_cpu == "x86") {
sources += [ "src/heap/base/asm/ia32/save_registers_masm.asm" ]
} else if (current_cpu == "arm64") {
sources += [ "src/heap/base/asm/arm64/save_registers_masm.S" ]
}
}
configs = [ ":internal_config" ]
[heap] Improve accounting of PagedSpace::CommittedPhysicalMemory() Instead of using the high water mark for determining this metric, we use a bitset for all active/used system pages on a V8 heap page. Each time when allocating a LAB on a page, we add the pages of that memory range to that bitset. During sweeping we rebuild that bitset from scratch and replace it with the old one in case free pages are discarded by the GC. We DCHECK here that the sweeper only ever removes pages. This has the nice benefit of ensuring that we don't miss any allocations (like we do now for concurrent allocations). CommittedPhysicalMemory for a page is then calculated by counting the set bits in the bitset and multiplying it with the system page size. This should be simpler to verify and track the "real" effective size more precisely. One case where we are partially less precise than the current implementation is for LABs. In order to reduce complexity we now treat all pages of a LAB allocation as active immediately. In the current implementation we tried to only account the actual used part of the LAB when changing the LAB later. This is more complex to track correctly but also doesn't account the currently used LAB in effective size. Change-Id: Ia83df9ad5fbb852f0717c4c396b5074604bd21e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497363 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#79428}
2022-03-09 16:49:56 +00:00
public_deps = [
":v8_heap_base_headers",
":v8_libbase",
]
}
# This is split out to be a non-code containing target that the Chromium browser
# can depend upon to get basic cppgc types.
v8_header_set("cppgc_headers") {
configs = [ ":internal_config" ]
public_configs = [
":v8_header_features",
":cppgc_header_features",
]
sources = [
"include/cppgc/allocation.h",
"include/cppgc/common.h",
"include/cppgc/cross-thread-persistent.h",
"include/cppgc/custom-space.h",
"include/cppgc/default-platform.h",
"include/cppgc/ephemeron-pair.h",
"include/cppgc/explicit-management.h",
"include/cppgc/garbage-collected.h",
"include/cppgc/heap-consistency.h",
"include/cppgc/heap-handle.h",
"include/cppgc/heap-state.h",
"include/cppgc/heap-statistics.h",
"include/cppgc/heap.h",
"include/cppgc/internal/api-constants.h",
"include/cppgc/internal/atomic-entry-flag.h",
"include/cppgc/internal/base-page-handle.h",
"include/cppgc/internal/compiler-specific.h",
"include/cppgc/internal/finalizer-trait.h",
"include/cppgc/internal/gc-info.h",
"include/cppgc/internal/member-storage.h",
"include/cppgc/internal/name-trait.h",
"include/cppgc/internal/persistent-node.h",
"include/cppgc/internal/pointer-policies.h",
"include/cppgc/internal/write-barrier.h",
"include/cppgc/liveness-broker.h",
"include/cppgc/macros.h",
"include/cppgc/member.h",
"include/cppgc/name-provider.h",
"include/cppgc/object-size-trait.h",
"include/cppgc/persistent.h",
"include/cppgc/platform.h",
"include/cppgc/prefinalizer.h",
"include/cppgc/process-heap-statistics.h",
"include/cppgc/sentinel-pointer.h",
"include/cppgc/source-location.h",
# TODO(v8:11952): Remove the testing header here once depending on both,
# //v8:v8 and //v8:v8_for_testing does not result in ODR violations.
"include/cppgc/testing.h",
"include/cppgc/trace-trait.h",
"include/cppgc/type-traits.h",
"include/cppgc/visitor.h",
]
if (cppgc_enable_caged_heap) {
sources += [ "include/cppgc/internal/caged-heap-local-data.h" ]
sources += [ "include/cppgc/internal/caged-heap.h" ]
}
deps = [
":v8_libbase",
":v8_libplatform",
]
public_deps = [ ":v8_config_headers" ]
}
v8_source_set("cppgc_base") {
visibility = [ ":*" ]
sources = [
"src/heap/cppgc/allocation.cc",
"src/heap/cppgc/compaction-worklists.cc",
"src/heap/cppgc/compaction-worklists.h",
"src/heap/cppgc/compactor.cc",
"src/heap/cppgc/compactor.h",
"src/heap/cppgc/concurrent-marker.cc",
"src/heap/cppgc/concurrent-marker.h",
"src/heap/cppgc/explicit-management.cc",
"src/heap/cppgc/free-list.cc",
"src/heap/cppgc/free-list.h",
"src/heap/cppgc/garbage-collector.h",
"src/heap/cppgc/gc-info-table.cc",
"src/heap/cppgc/gc-info-table.h",
"src/heap/cppgc/gc-info.cc",
"src/heap/cppgc/gc-invoker.cc",
"src/heap/cppgc/gc-invoker.h",
"src/heap/cppgc/globals.h",
"src/heap/cppgc/heap-base.cc",
"src/heap/cppgc/heap-base.h",
"src/heap/cppgc/heap-config.h",
"src/heap/cppgc/heap-consistency.cc",
"src/heap/cppgc/heap-growing.cc",
"src/heap/cppgc/heap-growing.h",
"src/heap/cppgc/heap-object-header.cc",
"src/heap/cppgc/heap-object-header.h",
"src/heap/cppgc/heap-page.cc",
"src/heap/cppgc/heap-page.h",
"src/heap/cppgc/heap-space.cc",
"src/heap/cppgc/heap-space.h",
"src/heap/cppgc/heap-state.cc",
"src/heap/cppgc/heap-statistics-collector.cc",
"src/heap/cppgc/heap-statistics-collector.h",
"src/heap/cppgc/heap-visitor.h",
"src/heap/cppgc/heap.cc",
"src/heap/cppgc/heap.h",
"src/heap/cppgc/incremental-marking-schedule.cc",
"src/heap/cppgc/incremental-marking-schedule.h",
"src/heap/cppgc/liveness-broker.cc",
"src/heap/cppgc/liveness-broker.h",
"src/heap/cppgc/logging.cc",
Reland "cppgc: Initial marking loop" This reverts commit dc1af6a2197ee3b967d601c5a967e9c625b629cf. Reason for revert: Diff in patchset 2 Original change's description: > Revert "cppgc: Initial marking loop" > > This reverts commit fb9a19fe0d7b15318ebc0d2afa85bacc70859082. > > Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/11028 > > Original change's description: > > cppgc: Initial marking loop > > > > This CL introduces: > > - Worklist > > - MarkingHandler to manage gc marking phase > > - Integration into CollectGarbage for atomic pause GC > > - MarkingVisitor for main thread marking > > > > Still missing from this CL: > > - Proper handling for stack scanning > > - Handling of previously not fully constructed objects > > > > Bug: chromium:1056170 > > Change-Id: I70ac8534dfb898777cf3a06e3119cac8072174fd > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170526 > > Commit-Queue: Omer Katz <omerkatz@chromium.org> > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#67642} > > TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org > > Change-Id: I666481f44119771be685bf2555aa0dd5eda83a01 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: chromium:1056170 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187502 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67643} TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org,nicohartmann@chromium.org # Not skipping CQ checks because this is a reland. Bug: chromium:1056170 Change-Id: I54e963e2aeaaf16069bdcdb019c0ac65e28ef6e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187733 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67654}
2020-05-07 12:16:20 +00:00
"src/heap/cppgc/marker.cc",
"src/heap/cppgc/marker.h",
"src/heap/cppgc/marking-state.cc",
"src/heap/cppgc/marking-state.h",
"src/heap/cppgc/marking-verifier.cc",
"src/heap/cppgc/marking-verifier.h",
Reland "cppgc: Initial marking loop" This reverts commit dc1af6a2197ee3b967d601c5a967e9c625b629cf. Reason for revert: Diff in patchset 2 Original change's description: > Revert "cppgc: Initial marking loop" > > This reverts commit fb9a19fe0d7b15318ebc0d2afa85bacc70859082. > > Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/11028 > > Original change's description: > > cppgc: Initial marking loop > > > > This CL introduces: > > - Worklist > > - MarkingHandler to manage gc marking phase > > - Integration into CollectGarbage for atomic pause GC > > - MarkingVisitor for main thread marking > > > > Still missing from this CL: > > - Proper handling for stack scanning > > - Handling of previously not fully constructed objects > > > > Bug: chromium:1056170 > > Change-Id: I70ac8534dfb898777cf3a06e3119cac8072174fd > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2170526 > > Commit-Queue: Omer Katz <omerkatz@chromium.org> > > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#67642} > > TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org > > Change-Id: I666481f44119771be685bf2555aa0dd5eda83a01 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: chromium:1056170 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187502 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67643} TBR=ulan@chromium.org,mlippautz@chromium.org,bikineev@chromium.org,omerkatz@chromium.org,nicohartmann@chromium.org # Not skipping CQ checks because this is a reland. Bug: chromium:1056170 Change-Id: I54e963e2aeaaf16069bdcdb019c0ac65e28ef6e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187733 Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67654}
2020-05-07 12:16:20 +00:00
"src/heap/cppgc/marking-visitor.cc",
"src/heap/cppgc/marking-visitor.h",
"src/heap/cppgc/marking-worklists.cc",
"src/heap/cppgc/marking-worklists.h",
"src/heap/cppgc/member-storage.cc",
"src/heap/cppgc/member-storage.h",
"src/heap/cppgc/memory.cc",
"src/heap/cppgc/memory.h",
"src/heap/cppgc/metric-recorder.h",
"src/heap/cppgc/name-trait.cc",
"src/heap/cppgc/object-allocator.cc",
"src/heap/cppgc/object-allocator.h",
"src/heap/cppgc/object-poisoner.h",
"src/heap/cppgc/object-size-trait.cc",
"src/heap/cppgc/object-start-bitmap.h",
"src/heap/cppgc/object-view.h",
"src/heap/cppgc/page-memory.cc",
"src/heap/cppgc/page-memory.h",
"src/heap/cppgc/persistent-node.cc",
"src/heap/cppgc/platform.cc",
"src/heap/cppgc/platform.h",
"src/heap/cppgc/pointer-policies.cc",
"src/heap/cppgc/prefinalizer-handler.cc",
"src/heap/cppgc/prefinalizer-handler.h",
"src/heap/cppgc/process-heap-statistics.cc",
"src/heap/cppgc/process-heap-statistics.h",
"src/heap/cppgc/process-heap.cc",
"src/heap/cppgc/process-heap.h",
"src/heap/cppgc/raw-heap.cc",
"src/heap/cppgc/raw-heap.h",
"src/heap/cppgc/remembered-set.cc",
"src/heap/cppgc/remembered-set.h",
"src/heap/cppgc/source-location.cc",
"src/heap/cppgc/stats-collector.cc",
"src/heap/cppgc/stats-collector.h",
"src/heap/cppgc/sweeper.cc",
"src/heap/cppgc/sweeper.h",
"src/heap/cppgc/task-handle.h",
"src/heap/cppgc/unmarker.h",
# TODO(v8:11952): Remove the testing header here once depending on both,
# //v8:v8 and //v8:v8_for_testing does not result in ODR violations.
"src/heap/cppgc/testing.cc",
"src/heap/cppgc/trace-event.h",
"src/heap/cppgc/trace-trait.cc",
"src/heap/cppgc/virtual-memory.cc",
"src/heap/cppgc/virtual-memory.h",
"src/heap/cppgc/visitor.cc",
"src/heap/cppgc/visitor.h",
"src/heap/cppgc/write-barrier.cc",
"src/heap/cppgc/write-barrier.h",
]
if (cppgc_enable_caged_heap) {
sources += [
"src/heap/cppgc/caged-heap-local-data.cc",
"src/heap/cppgc/caged-heap.cc",
"src/heap/cppgc/caged-heap.h",
]
}
configs = [
":internal_config",
":cppgc_base_config",
]
public_deps = [
":cppgc_headers",
":v8_heap_base",
":v8_libbase",
":v8_libplatform",
]
if (cppgc_is_standalone && !v8_use_perfetto) {
sources += [ "//base/trace_event/common/trace_event_common.h" ]
} else {
public_deps += [ ":v8_tracing" ]
}
}
if (v8_check_header_includes) {
# This file will be generated by tools/generate-header-include-checks.py
# if the "check_v8_header_includes" gclient variable is set.
import("check-header-includes/sources.gni")
v8_source_set("check_headers") {
Revert "[build] Separate out inspector as a shared library" This reverts commit 92bfb63cace73b967644abb6a26e8703350a7507. Reason for revert: Broke build https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20shared/43249/overview Original change's description: > [build] Separate out inspector as a shared library > > This makes src/inspector:inspector into a v8_component producing a > shared library in component builds. To enable this, all of its exported > are now marked with V8_INSPECTOR_EXPORT. > > This also inverts the dependency between src/inspector:inspector and > :v8_base_without_compiler, and instead makes d8 and some tests depend on > inspector rather than getting it via v8. > > As a result, the no_check_targets exclusions list in .gn is reduced. > > Ultimately embedders like chromium should depend on :v8 and optionally > src/inspector:inspector, but to allow that transition to occur, this > renames :v8 to :v8_lib and introduces a new :v8 which depends on v8 and > inspector. Once all embedders have changed to reflect the new structure, > this part can be reverted. > > Bug: v8:11917 > Change-Id: Ia8b15f07fb15acc5e1f111b1a80248def4285fd0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999088 > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75532} Bug: v8:11917 Change-Id: I0ed27ed95211d13b8b3438a8c0a42d577806c475 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3003452 Auto-Submit: Zhi An Ng <zhin@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75533}
2021-07-02 16:14:44 +00:00
configs = [ ":internal_config" ]
sources = check_header_includes_sources
# Any rules that contain headers files should be added here either directly
# or indirectly by including something that has it transitively in its
# public_deps.
deps = [
":d8",
":mksnapshot",
":torque_base",
":torque_ls_base",
":v8_base_without_compiler",
":v8_bigint",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
":v8_headers",
":v8_initializers",
":v8_internal_headers",
":v8_libbase",
":v8_maybe_icu",
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
":v8_version",
":wee8",
"src/inspector:inspector",
"src/inspector:inspector_string_conversions",
]
}
}
###############################################################################
# Produce a single static library for embedders
#
if (v8_monolithic) {
# A component build is not monolithic.
assert(!is_component_build)
# Using external startup data would produce separate files.
assert(!v8_use_external_startup_data)
v8_static_library("v8_monolith") {
deps = [
":v8",
":v8_libbase",
":v8_libplatform",
"//build/win:default_exe_manifest",
]
configs = [ ":internal_config" ]
}
}
if (v8_enable_webassembly) {
v8_static_library("wee8") {
deps = [
":v8_base",
":v8_libbase",
":v8_libplatform",
":v8_shared_internal_headers",
":v8_snapshot",
"//build/win:default_exe_manifest",
]
# TODO: v8dll-main.cc equivalent for shared library builds
configs = [ ":internal_config" ]
sources = [
### gcmole(all) ###
"src/wasm/c-api.cc",
"src/wasm/c-api.h",
"third_party/wasm-api/wasm.h",
"third_party/wasm-api/wasm.hh",
]
}
}
###############################################################################
# Executables
#
if (current_toolchain == v8_generator_toolchain) {
v8_executable("bytecode_builtins_list_generator") {
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
visibility = [ ":*" ] # Only targets in this file can depend on this.
include_dirs = [ "." ]
sources = [
"src/builtins/generate-bytecodes-builtins-list.cc",
"src/interpreter/bytecode-operands.cc",
"src/interpreter/bytecode-operands.h",
"src/interpreter/bytecode-traits.h",
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
"src/interpreter/bytecodes.cc",
"src/interpreter/bytecodes.h",
]
configs = [ ":internal_config" ]
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
deps = [
":v8_libbase",
":v8_shared_internal_headers",
[embedded handlers] Store the handlers without gaps Previously the builtins table had a value for every single OperandScale/Bytecode combination regardless of whether it was valid. This change makes it so that only valid bytecode handlers are stored in the builtins table. This prevents placeholders being serialized into the snapshot (and embedded into the binary) saving 9KB in CODE_SPACE/OLD_SPACE and 2.5KB in the embedded data as well as 66 entries in the builtins table. To do this, it generates a new header file bytecodes-builtins-list.h which is created from the BYTECODE_LIST and OPERAND_SCALE_LIST macros. Since list macros cannot be used to conditionally generate elements in the C-preprocessor, this is done by generator executable, compiled from interpreter/generate-flat-headers.cc. Additionally the generator creates the flat bytecode list so that it is transposed from the previous result, i.e. the results are grouped by bytecode and then operand scale rather than operand scale then bytecode. This should give better locality for commonly used bytecodes and may allow less commonly used ExtraWide bytecodes to never be mapped into memory at all. The cost to storing the handlers densely is that looking up a handler now requires a binary search through the builtins table, but this should only happen during debugging. It is also fixable at least for non-wide handlers and could be improved for wide ones if the need arises. Bug: v8:8068 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Iaad22a952e2858f508030c5ddc082f91bf59f667 Reviewed-on: https://chromium-review.googlesource.com/1209304 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#55757}
2018-09-10 12:55:45 +00:00
"//build/win:default_exe_manifest",
]
}
}
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
if (current_toolchain == v8_snapshot_toolchain) {
v8_executable("mksnapshot") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [
"src/snapshot/embedded/embedded-empty.cc",
"src/snapshot/embedded/embedded-file-writer.cc",
"src/snapshot/embedded/embedded-file-writer.h",
"src/snapshot/embedded/platform-embedded-file-writer-aix.cc",
"src/snapshot/embedded/platform-embedded-file-writer-aix.h",
"src/snapshot/embedded/platform-embedded-file-writer-base.cc",
"src/snapshot/embedded/platform-embedded-file-writer-base.h",
"src/snapshot/embedded/platform-embedded-file-writer-generic.cc",
"src/snapshot/embedded/platform-embedded-file-writer-generic.h",
"src/snapshot/embedded/platform-embedded-file-writer-mac.cc",
"src/snapshot/embedded/platform-embedded-file-writer-mac.h",
"src/snapshot/embedded/platform-embedded-file-writer-win.cc",
"src/snapshot/embedded/platform-embedded-file-writer-win.h",
"src/snapshot/mksnapshot.cc",
"src/snapshot/snapshot-empty.cc",
"src/snapshot/static-roots-gen.cc",
"src/snapshot/static-roots-gen.h",
]
if (v8_control_flow_integrity) {
sources += [ "src/deoptimizer/deoptimizer-cfi-empty.cc" ]
}
configs = [ ":internal_config" ]
deps = [
":v8_base_without_compiler",
":v8_compiler_for_mksnapshot",
":v8_init",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
":v8_libbase",
":v8_libplatform",
":v8_maybe_icu",
":v8_shared_internal_headers",
":v8_tracing",
":v8_turboshaft",
"//build/win:default_exe_manifest",
]
}
}
if (current_toolchain == v8_snapshot_toolchain) {
v8_executable("torque") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [ "src/torque/torque.cc" ]
deps = [
":torque_base",
"//build/win:default_exe_manifest",
]
# The use of exceptions for Torque in violation of the Chromium style-guide
# is justified by the fact that it is only used from the non-essential
# language server and can be removed anytime if it causes problems.
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
configs = [
":internal_config",
"//build/config/compiler:exceptions",
"//build/config/compiler:rtti",
]
remove_configs = [
"//build/config/compiler:no_exceptions",
"//build/config/compiler:no_rtti",
]
if (is_win && is_asan) {
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
remove_configs += [ "//build/config/sanitizers:default_sanitizer_flags" ]
}
}
}
v8_executable("torque-language-server") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [ "src/torque/ls/torque-language-server.cc" ]
deps = [
":torque_base",
":torque_ls_base",
"//build/win:default_exe_manifest",
]
# The use of exceptions for Torque in violation of the Chromium style-guide
# is justified by the fact that it is only used from the non-essential
# language server and can be removed anytime if it causes problems.
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
configs = [
":internal_config",
"//build/config/compiler:exceptions",
"//build/config/compiler:rtti",
]
remove_configs = [
"//build/config/compiler:no_exceptions",
"//build/config/compiler:no_rtti",
]
if (is_win && is_asan) {
Reland^3 "[torque] Throw exception instead of aborting if something goes wrong" This is a reland of ffe6940fbc47832a33198c2f7515019e98a8328d The UBSan issue is fixed with https://crrev.com/c/1566511 TBR=tebbi@chromium.org Original change's description: > Reland^2 "[torque] Throw exception instead of aborting if something goes wrong" > > This is a reland of 251d1623f34fba74fb84262914946840c5cd629c > > The reland fixes ASAN component builds by adding RTTI build config to both > torque executables. Big thanks to sigurds for finding the fix. > > Original change's description: > > Reland "[torque] Throw exception instead of aborting if something goes wrong" > > > > This is a reland of 3bd49f9b902d216ee6441683a6a608eaae521c47 > > > > The issue on the windows bot is apparently a compiler bug in MSVC related to > > move construction. The fix seems to be to change the order of the fields in > > "JsonParseResult" (go figure). > > > > Drive-by-change: Fix LS on windows by emitting correct line endings and > > enabling exceptions for the LS executable as well. > > > > Original change's description: > > > [torque] Throw exception instead of aborting if something goes wrong > > > > > > This CL enables exceptions for the Torque compiler and Torque language > > > server. Instead of aborting when something goes wrong during > > > compilation, a TorqueError is thrown, containing the error message > > > and a source position. The compiler executable still prints the error > > > and aborts, while the language server will pass this information > > > along to the client (not included in this CL). > > > > > > R=danno@chromium.org > > > > > > Bug: v8:8880 > > > Change-Id: Iad83c46fb6a91c1babbc0ae7dbd94fbe4e7f1663 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526003 > > > Reviewed-by: Daniel Clifford <danno@chromium.org> > > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#60512} > > > > Bug: v8:8880 > > Change-Id: I00e6591bbb4c516dd7540a7e27196853bc637f11 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545995 > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Commit-Queue: Simon Zünd <szuend@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#60736} > > Bug: v8:8880 > Change-Id: Iba198d771169283e83e74324f27aa9e90b8d8975 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1563770 > Reviewed-by: Sigurd Schneider <sigurds@chromium.org> > Commit-Queue: Simon Zünd <szuend@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60804} Bug: v8:8880 Change-Id: I5b7e40ad27bff8f7bfa22240954c2cb75083ad82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564065 Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#60860}
2019-04-12 04:06:41 +00:00
remove_configs += [ "//build/config/sanitizers:default_sanitizer_flags" ]
}
}
if (v8_enable_i18n_support) {
if (current_toolchain == v8_generator_toolchain) {
v8_executable("gen-regexp-special-case") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [
"src/regexp/gen-regexp-special-case.cc",
"src/regexp/special-case.h",
]
deps = [
":v8_libbase",
":v8_shared_internal_headers",
"//build/win:default_exe_manifest",
"//third_party/icu",
]
configs = [ ":internal_config" ]
}
}
action("run_gen-regexp-special-case") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
script = "tools/run.py"
deps = [ ":gen-regexp-special-case($v8_generator_toolchain)" ]
output_file = "$target_gen_dir/src/regexp/special-case.cc"
outputs = [ output_file ]
args = [
"./" + rebase_path(
get_label_info(
":gen-regexp-special-case($v8_generator_toolchain)",
"root_out_dir") + "/gen-regexp-special-case",
root_build_dir),
rebase_path(output_file, root_build_dir),
]
}
}
###############################################################################
# Public targets
#
want_v8_shell =
(current_toolchain == host_toolchain && v8_toolset_for_shell == "host") ||
(current_toolchain == v8_snapshot_toolchain &&
v8_toolset_for_shell == "host") ||
(current_toolchain != host_toolchain && v8_toolset_for_shell == "target")
group("gn_all") {
testonly = true
deps = [
":d8",
":v8_fuzzers",
":v8_hello_world",
":v8_sample_process",
"test:gn_all",
"tools:gn_all",
]
if (v8_custom_deps != "") {
# Custom dependency from directory under v8/custom_deps.
deps += [ v8_custom_deps ]
}
if (want_v8_shell) {
deps += [ ":v8_shell" ]
}
if (v8_check_header_includes) {
deps += [ ":check_headers" ]
}
}
group("v8_python_base") {
data = [ ".vpython3" ]
}
group("v8_clusterfuzz") {
testonly = true
deps = [
":d8",
":v8_simple_inspector_fuzzer",
"tools/clusterfuzz/trials:v8_clusterfuzz_resources",
]
if (v8_multi_arch_build) {
deps += [
":d8(//build/toolchain/linux:clang_x64)",
":d8(//build/toolchain/linux:clang_x64_v8_arm64)",
":d8(//build/toolchain/linux:clang_x86)",
":d8(//build/toolchain/linux:clang_x86_v8_arm)",
":d8(tools/clusterfuzz/foozzie/toolchain:clang_x64_pointer_compression)",
]
}
}
# Targets we ensure work with gcc. The aim is to keep this list small to have
# a fast overall compile time.
group("v8_gcc_light") {
testonly = true
deps = [ ":d8" ]
}
group("v8_archive") {
testonly = true
deps = [ ":d8" ]
if (!is_win) {
# On windows, cctest doesn't link with v8_static_library.
deps += [ "test/cctest:cctest" ]
}
}
# TODO(dglazkov): Remove the "!build_with_chromium" condition once this clause
# is removed from Chromium.
if (is_fuchsia && !build_with_chromium) {
import("//build/config/fuchsia/generate_runner_scripts.gni")
import("//third_party/fuchsia-sdk/sdk/build/component.gni")
import("//third_party/fuchsia-sdk/sdk/build/package.gni")
fuchsia_component("d8_component") {
testonly = true
manifest = "gni/v8.cml"
data_deps = [ ":d8" ]
}
fuchsia_package("d8_pkg") {
testonly = true
package_name = "d8"
deps = [ ":d8_component" ]
}
fuchsia_package_installer("d8_fuchsia") {
testonly = true
package = ":d8_pkg"
package_name = "d8"
}
}
group("v8_fuzzers") {
testonly = true
data_deps = [
":v8_simple_inspector_fuzzer",
":v8_simple_json_fuzzer",
":v8_simple_parser_fuzzer",
":v8_simple_regexp_builtins_fuzzer",
":v8_simple_regexp_fuzzer",
]
if (v8_enable_webassembly) {
data_deps += [
":v8_simple_multi_return_fuzzer",
":v8_simple_wasm_async_fuzzer",
":v8_simple_wasm_code_fuzzer",
":v8_simple_wasm_compile_fuzzer",
":v8_simple_wasm_fuzzer",
":v8_simple_wasm_streaming_fuzzer",
]
}
}
if (is_component_build) {
v8_component("v8") {
sources = [ "src/utils/v8dll-main.cc" ]
public_deps = [
":v8_base",
":v8_snapshot",
]
configs = [ ":internal_config" ]
public_configs = [ ":external_config" ]
}
v8_component("v8_for_testing") {
testonly = true
sources = [ "src/utils/v8dll-main.cc" ]
public_deps = [
":torque_base",
":torque_ls_base",
":v8_base",
":v8_headers",
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
":v8_initializers",
":v8_snapshot",
]
configs = [ ":internal_config" ]
public_configs = [ ":external_config" ]
}
v8_component("cppgc") {
public_deps = [ ":cppgc_base" ]
if (!cppgc_is_standalone) {
deps = [ ":v8" ]
}
configs = []
public_configs = [ ":external_config" ]
}
if (cppgc_is_standalone) {
v8_component("cppgc_for_testing") {
testonly = true
public_deps = [ ":cppgc_base" ]
configs = []
public_configs = [ ":external_config" ]
}
}
v8_component("v8_heap_base_for_testing") {
testonly = true
public_deps = [ ":v8_heap_base" ]
configs = []
public_configs = [ ":external_config" ]
}
} else {
group("v8") {
public_deps = [
":v8_base",
":v8_snapshot",
]
public_configs = [ ":external_config" ]
}
group("v8_for_testing") {
testonly = true
public_deps = [
":torque_base",
":torque_ls_base",
":v8_base",
Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" This is a reland of 1c56974f2a7935986762473285369bb45be7917c This is a plain reland of the original CL. The original CL was speculatively reverted, but ended up not being the cause for bot failures. Original change's description: > Unconditionally enable snapshot builds and remove 'v8_use_snapshot' > > This CL removes 'v8_use_snapshot' and the usages of the implied > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the > "asan" variant instead of the now obsolete "no_snap" variant. > > Related chromium CL: https://crrev.com/c/1796325. > > Bug: v8:8531 > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282 > Commit-Queue: Simon Zünd <szuend@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Nico Weber <thakis@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64290} TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org Bug: v8:8531 Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649 Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Tamer Tas <tmrts@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Cr-Commit-Position: refs/heads/master@{#64305}
2019-10-15 06:51:14 +00:00
":v8_initializers",
":v8_snapshot",
]
public_configs = [ ":external_config" ]
}
group("cppgc") {
public_deps = [ ":cppgc_base" ]
if (!cppgc_is_standalone) {
deps = [ ":v8" ]
}
public_configs = [ ":external_config" ]
}
if (cppgc_is_standalone) {
group("cppgc_for_testing") {
testonly = true
public_deps = [ ":cppgc_base" ]
public_configs = [ ":external_config" ]
}
}
group("v8_heap_base_for_testing") {
testonly = true
public_deps = [ ":v8_heap_base" ]
public_configs = [ ":external_config" ]
}
}
v8_executable("d8") {
sources = [
"src/d8/async-hooks-wrapper.cc",
"src/d8/async-hooks-wrapper.h",
"src/d8/d8-console.cc",
"src/d8/d8-console.h",
"src/d8/d8-js.cc",
"src/d8/d8-platforms.cc",
"src/d8/d8-platforms.h",
Reland "[fastcall] Add fast API testing facilities to d8" This is a reland of 9eba2d85f420933c9c97caebf357b257b00dc93f. The reland fixes a global state variable which was incompatible with the --isolate flag in d8, which runs the same script in a different isolate. Original change's description: > [fastcall] Add fast API testing facilities to d8 > > This CL provides the minimum necessary functionality to expose fast API > for testing in mjsunit, exposing the fast path for fuzzing. It exposes > a d8.test.fast_c_api with an `add_all` method, which exercises primitive > types. On x64, all integer and floating point types are supported. On > other platforms currently only 32-bit integers are included in the test. > > Design doc: > https://docs.google.com/document/d/1KUKPfXkSRZTA2gMwaWbpQKlYfw0C-T6AE3XzC4viHbo/ > > Bug: chromium:1052746 > Change-Id: Icc824199a26dd2abd2b869f5483a39d38e4dce3e > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2749154 > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> > Commit-Queue: Maya Lekova <mslekova@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73670} Bug: chromium:1052746 Change-Id: I33b265b97bf7c797eee7d4cce5066999358a8c66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2790174 Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#73801}
2021-04-06 06:46:11 +00:00
"src/d8/d8-test.cc",
"src/d8/d8.cc",
"src/d8/d8.h",
]
if (v8_fuzzilli) {
sources += [
"src/d8/cov.cc",
"src/d8/cov.h",
]
}
configs = [
# Note: don't use :internal_config here because this target will get
# the :external_config applied to it by virtue of depending on :v8, and
# you can't have both applied to the same target.
":internal_config_base",
":v8_tracing_config",
]
deps = [
":v8",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
":v8_libbase",
":v8_libplatform",
":v8_tracing",
"//build/win:default_exe_manifest",
]
if (is_posix || is_fuchsia) {
sources += [ "src/d8/d8-posix.cc" ]
} else if (is_win) {
sources += [ "src/d8/d8-windows.cc" ]
}
if (v8_correctness_fuzzer) {
deps += [ "tools/clusterfuzz/foozzie:v8_correctness_fuzzer_resources" ]
}
defines = []
if (v8_enable_vtunejit) {
deps += [ "src/third_party/vtune:v8_vtune" ]
}
}
v8_executable("v8_hello_world") {
sources = [ "samples/hello-world.cc" ]
configs = [
# Note: don't use :internal_config here because this target will get
# the :external_config applied to it by virtue of depending on :v8, and
# you can't have both applied to the same target.
":internal_config_base",
]
deps = [
":v8",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
":v8_libbase",
":v8_libplatform",
"//build/win:default_exe_manifest",
]
}
v8_executable("v8_sample_process") {
sources = [ "samples/process.cc" ]
configs = [
# Note: don't use :internal_config here because this target will get
# the :external_config applied to it by virtue of depending on :v8, and
# you can't have both applied to the same target.
":internal_config_base",
]
deps = [
":v8",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
":v8_libbase",
":v8_libplatform",
"//build/win:default_exe_manifest",
]
}
if (want_v8_shell) {
v8_executable("v8_shell") {
sources = [ "samples/shell.cc" ]
configs = [
# Note: don't use :internal_config here because this target will get
# the :external_config applied to it by virtue of depending on :v8, and
# you can't have both applied to the same target.
":internal_config_base",
]
if (is_win && !v8_enable_cet_shadow_stack) {
v8_remove_configs += [ "//build/config/compiler:cet_shadow_stack" ]
}
deps = [
":v8",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
":v8_libbase",
":v8_libplatform",
"//build/win:default_exe_manifest",
]
}
}
v8_executable("cppgc_hello_world") {
sources = [ "samples/cppgc/hello-world.cc" ]
if (v8_current_cpu == "riscv64" || v8_current_cpu == "riscv32") {
libs = [ "atomic" ]
}
configs = [
# Note: don't use :internal_config here because this target will get
# the :external_config applied to it by virtue of depending on :cppgc, and
# you can't have both applied to the same target.
":internal_config_base",
":cppgc_base_config",
]
deps = [ ":cppgc" ]
if (!cppgc_is_standalone) {
deps += [
":v8",
"//build/win:default_exe_manifest",
]
}
}
template("v8_fuzzer") {
name = target_name
forward_variables_from(invoker, "*")
v8_executable("v8_simple_" + name) {
deps = [
":" + name,
"//build/win:default_exe_manifest",
]
sources = [ "test/fuzzer/fuzzer.cc" ]
configs = [ ":external_config" ]
}
}
v8_source_set("json_fuzzer") {
sources = [ "test/fuzzer/json.cc" ]
deps = [ ":fuzzer_support" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("json_fuzzer") {
}
v8_source_set("parser_fuzzer") {
sources = [ "test/fuzzer/parser.cc" ]
deps = [ ":fuzzer_support" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("parser_fuzzer") {
}
v8_source_set("regexp_builtins_fuzzer") {
sources = [
"test/fuzzer/regexp-builtins.cc",
"test/fuzzer/regexp_builtins/mjsunit.js.h",
]
deps = [ ":fuzzer_support" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("regexp_builtins_fuzzer") {
}
v8_source_set("regexp_fuzzer") {
sources = [ "test/fuzzer/regexp.cc" ]
deps = [ ":fuzzer_support" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("regexp_fuzzer") {
}
if (v8_enable_webassembly) {
v8_source_set("multi_return_fuzzer") {
sources = [ "test/fuzzer/multi-return.cc" ]
deps = [ ":fuzzer_support" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("multi_return_fuzzer") {
}
v8_source_set("wasm_test_common") {
sources = [
"test/common/flag-utils.h",
"test/common/wasm/flag-utils.h",
"test/common/wasm/wasm-interpreter.cc",
"test/common/wasm/wasm-interpreter.h",
"test/common/wasm/wasm-module-runner.cc",
"test/common/wasm/wasm-module-runner.h",
]
deps = [
":generate_bytecode_builtins_list",
":run_torque",
":v8_internal_headers",
":v8_libbase",
":v8_shared_internal_headers",
":v8_tracing",
]
Revert "Reland "[DEPS] Add abseil to deps"" This reverts commit 214ef26dd0bfd3a2794d8ec37f998c78bcfdaa27. Reason for revert: gcc bots are failing https://crbug.com/v8/12248 Original change's description: > Reland "[DEPS] Add abseil to deps" > > This is a reland of 3c49308ac6acbb7d41c01b0c3d8bd14604ea7b06 > > Original change's description: > > [DEPS] Add abseil to deps > > > > Add a dependency on the chromium abseil-cpp subdir mirror. > > > > Bug: v8:11006 > > Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70786} > > Bug: v8:11006 > Change-Id: I2befd2eadd11d485eee47c68119d93be9a3e1655 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504257 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76897} Bug: v8:11006 Change-Id: Icdc7ed108a49fa33a0233a1af8ba8e4d9daadfd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3191392 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77132}
2021-09-28 17:44:04 +00:00
public_deps = [ ":v8_maybe_icu" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_source_set("wasm_fuzzer") {
sources = [ "test/fuzzer/wasm.cc" ]
deps = [
":fuzzer_support",
":lib_wasm_fuzzer_common",
":wasm_test_common",
]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("wasm_fuzzer") {
}
v8_source_set("wasm_async_fuzzer") {
sources = [ "test/fuzzer/wasm-async.cc" ]
deps = [
":fuzzer_support",
":lib_wasm_fuzzer_common",
":wasm_test_common",
]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("wasm_async_fuzzer") {
}
v8_source_set("wasm_code_fuzzer") {
sources = [
"test/common/wasm/test-signatures.h",
"test/fuzzer/wasm-code.cc",
]
deps = [
":fuzzer_support",
":lib_wasm_fuzzer_common",
":wasm_test_common",
]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("wasm_code_fuzzer") {
}
v8_source_set("lib_wasm_fuzzer_common") {
sources = [
"test/fuzzer/wasm-fuzzer-common.cc",
"test/fuzzer/wasm-fuzzer-common.h",
]
deps = [
":fuzzer_support",
":generate_bytecode_builtins_list",
":run_torque",
":v8_internal_headers",
":v8_tracing",
":wasm_test_common",
]
Revert "Reland "[DEPS] Add abseil to deps"" This reverts commit 214ef26dd0bfd3a2794d8ec37f998c78bcfdaa27. Reason for revert: gcc bots are failing https://crbug.com/v8/12248 Original change's description: > Reland "[DEPS] Add abseil to deps" > > This is a reland of 3c49308ac6acbb7d41c01b0c3d8bd14604ea7b06 > > Original change's description: > > [DEPS] Add abseil to deps > > > > Add a dependency on the chromium abseil-cpp subdir mirror. > > > > Bug: v8:11006 > > Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Yang Guo <yangguo@chromium.org> > > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70786} > > Bug: v8:11006 > Change-Id: I2befd2eadd11d485eee47c68119d93be9a3e1655 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504257 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Adam Klein <adamk@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76897} Bug: v8:11006 Change-Id: Icdc7ed108a49fa33a0233a1af8ba8e4d9daadfd8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3191392 Reviewed-by: Adam Klein <adamk@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77132}
2021-09-28 17:44:04 +00:00
public_deps = [ ":v8_maybe_icu" ]
configs = [
":external_config",
":internal_config_base",
]
}
v8_source_set("wasm_compile_fuzzer") {
sources = [
"test/common/wasm/test-signatures.h",
"test/fuzzer/wasm-compile.cc",
]
[wasm] Syntax- and Type-aware Fuzzer This is the beginning of a new fuzzer that generates correct-by-construction Wasm modules. This should allow us to better exercise the compiler and correctness aspects of fuzzing. It is based off of ahaas' original Wasm fuzzer. At the moment, it can generate expressions made up of most binops, and also nested blocks with unconditional breaks. Future CLs will add additional constructs, such as br_if, loops, memory access, etc. The way the fuzzer works is that it starts with an array of arbitrary data provided by libfuzzer. It uses the data to generate an expression. Care is taken to make use of the entire string. Basically, the generator has a bunch of grammar-like rules for how to construct an expression of a given type. For example, an i32 can be made by adding two other i32s, or by wrapping an i64. The process then continues recursively until all the data is consumed. We generate an expression from a slice of data as follows: * If the slice is less than or equal to the size of the type (e.g. 4 bytes for i32), then it will emit the entire slice as a constant. * Otherwise, it will consume the first 4 bytes of the slice and use this to select which rule to apply. Each rule then consumes the remainder of the slice in an appropriate way. For example: * Unary ops use the remainder of the slice to generate the argument. * Binary ops consume another four bytes and mod this with the length of the remaining slice to split the slice into two parts. Each of these subslices are then used to generate one of the arguments to the binop. * Blocks are basically like a unary op, but a stack of block types is maintained to facilitate branches. For blocks that end in a break, the first four bytes of a slice are used to select the break depth and the stack determines what type of expression to generate. The goal is that once this generator is complete, it will provide a one to one mapping between binary strings and valid Wasm modules. Review-Url: https://codereview.chromium.org/2658723006 Cr-Commit-Position: refs/heads/master@{#43289}
2017-02-17 17:06:29 +00:00
deps = [
":fuzzer_support",
":lib_wasm_fuzzer_common",
":wasm_test_common",
]
[wasm] Syntax- and Type-aware Fuzzer This is the beginning of a new fuzzer that generates correct-by-construction Wasm modules. This should allow us to better exercise the compiler and correctness aspects of fuzzing. It is based off of ahaas' original Wasm fuzzer. At the moment, it can generate expressions made up of most binops, and also nested blocks with unconditional breaks. Future CLs will add additional constructs, such as br_if, loops, memory access, etc. The way the fuzzer works is that it starts with an array of arbitrary data provided by libfuzzer. It uses the data to generate an expression. Care is taken to make use of the entire string. Basically, the generator has a bunch of grammar-like rules for how to construct an expression of a given type. For example, an i32 can be made by adding two other i32s, or by wrapping an i64. The process then continues recursively until all the data is consumed. We generate an expression from a slice of data as follows: * If the slice is less than or equal to the size of the type (e.g. 4 bytes for i32), then it will emit the entire slice as a constant. * Otherwise, it will consume the first 4 bytes of the slice and use this to select which rule to apply. Each rule then consumes the remainder of the slice in an appropriate way. For example: * Unary ops use the remainder of the slice to generate the argument. * Binary ops consume another four bytes and mod this with the length of the remaining slice to split the slice into two parts. Each of these subslices are then used to generate one of the arguments to the binop. * Blocks are basically like a unary op, but a stack of block types is maintained to facilitate branches. For blocks that end in a break, the first four bytes of a slice are used to select the break depth and the stack determines what type of expression to generate. The goal is that once this generator is complete, it will provide a one to one mapping between binary strings and valid Wasm modules. Review-Url: https://codereview.chromium.org/2658723006 Cr-Commit-Position: refs/heads/master@{#43289}
2017-02-17 17:06:29 +00:00
configs = [
":external_config",
":internal_config_base",
]
}
[wasm] Syntax- and Type-aware Fuzzer This is the beginning of a new fuzzer that generates correct-by-construction Wasm modules. This should allow us to better exercise the compiler and correctness aspects of fuzzing. It is based off of ahaas' original Wasm fuzzer. At the moment, it can generate expressions made up of most binops, and also nested blocks with unconditional breaks. Future CLs will add additional constructs, such as br_if, loops, memory access, etc. The way the fuzzer works is that it starts with an array of arbitrary data provided by libfuzzer. It uses the data to generate an expression. Care is taken to make use of the entire string. Basically, the generator has a bunch of grammar-like rules for how to construct an expression of a given type. For example, an i32 can be made by adding two other i32s, or by wrapping an i64. The process then continues recursively until all the data is consumed. We generate an expression from a slice of data as follows: * If the slice is less than or equal to the size of the type (e.g. 4 bytes for i32), then it will emit the entire slice as a constant. * Otherwise, it will consume the first 4 bytes of the slice and use this to select which rule to apply. Each rule then consumes the remainder of the slice in an appropriate way. For example: * Unary ops use the remainder of the slice to generate the argument. * Binary ops consume another four bytes and mod this with the length of the remaining slice to split the slice into two parts. Each of these subslices are then used to generate one of the arguments to the binop. * Blocks are basically like a unary op, but a stack of block types is maintained to facilitate branches. For blocks that end in a break, the first four bytes of a slice are used to select the break depth and the stack determines what type of expression to generate. The goal is that once this generator is complete, it will provide a one to one mapping between binary strings and valid Wasm modules. Review-Url: https://codereview.chromium.org/2658723006 Cr-Commit-Position: refs/heads/master@{#43289}
2017-02-17 17:06:29 +00:00
v8_fuzzer("wasm_compile_fuzzer") {
}
v8_source_set("wasm_streaming_fuzzer") {
sources = [ "test/fuzzer/wasm-streaming.cc" ]
deps = [
":fuzzer_support",
":lib_wasm_fuzzer_common",
":wasm_test_common",
]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("wasm_streaming_fuzzer") {
}
[wasm] Syntax- and Type-aware Fuzzer This is the beginning of a new fuzzer that generates correct-by-construction Wasm modules. This should allow us to better exercise the compiler and correctness aspects of fuzzing. It is based off of ahaas' original Wasm fuzzer. At the moment, it can generate expressions made up of most binops, and also nested blocks with unconditional breaks. Future CLs will add additional constructs, such as br_if, loops, memory access, etc. The way the fuzzer works is that it starts with an array of arbitrary data provided by libfuzzer. It uses the data to generate an expression. Care is taken to make use of the entire string. Basically, the generator has a bunch of grammar-like rules for how to construct an expression of a given type. For example, an i32 can be made by adding two other i32s, or by wrapping an i64. The process then continues recursively until all the data is consumed. We generate an expression from a slice of data as follows: * If the slice is less than or equal to the size of the type (e.g. 4 bytes for i32), then it will emit the entire slice as a constant. * Otherwise, it will consume the first 4 bytes of the slice and use this to select which rule to apply. Each rule then consumes the remainder of the slice in an appropriate way. For example: * Unary ops use the remainder of the slice to generate the argument. * Binary ops consume another four bytes and mod this with the length of the remaining slice to split the slice into two parts. Each of these subslices are then used to generate one of the arguments to the binop. * Blocks are basically like a unary op, but a stack of block types is maintained to facilitate branches. For blocks that end in a break, the first four bytes of a slice are used to select the break depth and the stack determines what type of expression to generate. The goal is that once this generator is complete, it will provide a one to one mapping between binary strings and valid Wasm modules. Review-Url: https://codereview.chromium.org/2658723006 Cr-Commit-Position: refs/heads/master@{#43289}
2017-02-17 17:06:29 +00:00
}
v8_source_set("inspector_fuzzer") {
sources = [ "test/fuzzer/inspector-fuzzer.cc" ]
deps = [
":fuzzer_support",
"test/inspector:inspector_test",
]
configs = [
":external_config",
":internal_config_base",
]
}
v8_fuzzer("inspector_fuzzer") {
}
# Target to build all generated .cc files.
group("v8_generated_cc_files") {
testonly = true
deps = [
":generate_bytecode_builtins_list",
":run_torque",
"src/inspector:v8_generated_cc_files",
]
}
# Protobuf targets, used only when building outside of chromium.
if (!build_with_chromium && v8_use_perfetto) {
# This config is applied to the autogenerated .pb.{cc,h} files in
# proto_library.gni. This config is propagated up to the source sets
# that depend on generated proto headers.
config("protobuf_gen_config") {
defines = [
"GOOGLE_PROTOBUF_NO_RTTI",
"GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER",
]
cflags = [
"-Wno-unknown-warning-option",
"-Wno-deprecated",
"-Wno-undef",
"-Wno-zero-as-null-pointer-constant",
"-Wno-thread-safety-attributes",
]
include_dirs = [ "third_party/protobuf/src" ]
}
# Configuration used to build libprotobuf_* and the protoc compiler.
config("protobuf_config") {
# Apply the lighter supressions and macro definitions from above.
configs = [ ":protobuf_gen_config" ]
if (!is_win) {
defines = [ "HAVE_PTHREAD=1" ]
}
if (is_clang) {
cflags = [
"-Wno-unused-private-field",
"-Wno-unused-function",
"-Wno-inconsistent-missing-override",
"-Wno-unknown-warning-option",
"-Wno-enum-compare-switch",
"-Wno-user-defined-warnings",
"-Wno-tautological-constant-compare",
]
}
if (is_win && is_clang) {
cflags += [ "-Wno-microsoft-unqualified-friend" ]
}
}
source_set("protobuf_lite") {
sources = [
"third_party/protobuf/src/google/protobuf/any_lite.cc",
"third_party/protobuf/src/google/protobuf/arena.cc",
"third_party/protobuf/src/google/protobuf/arena.h",
"third_party/protobuf/src/google/protobuf/arena_impl.h",
"third_party/protobuf/src/google/protobuf/arenastring.h",
"third_party/protobuf/src/google/protobuf/extension_set.cc",
"third_party/protobuf/src/google/protobuf/extension_set.h",
"third_party/protobuf/src/google/protobuf/generated_enum_util.cc",
"third_party/protobuf/src/google/protobuf/generated_enum_util.h",
"third_party/protobuf/src/google/protobuf/generated_message_table_driven_lite.cc",
"third_party/protobuf/src/google/protobuf/generated_message_table_driven_lite.h",
"third_party/protobuf/src/google/protobuf/generated_message_util.cc",
"third_party/protobuf/src/google/protobuf/generated_message_util.h",
"third_party/protobuf/src/google/protobuf/has_bits.h",
"third_party/protobuf/src/google/protobuf/implicit_weak_message.cc",
"third_party/protobuf/src/google/protobuf/implicit_weak_message.h",
"third_party/protobuf/src/google/protobuf/inlined_string_field.h",
"third_party/protobuf/src/google/protobuf/io/coded_stream.cc",
"third_party/protobuf/src/google/protobuf/io/coded_stream.h",
"third_party/protobuf/src/google/protobuf/io/coded_stream_inl.h",
"third_party/protobuf/src/google/protobuf/io/io_win32.cc",
"third_party/protobuf/src/google/protobuf/io/io_win32.h",
"third_party/protobuf/src/google/protobuf/io/strtod.cc",
"third_party/protobuf/src/google/protobuf/io/strtod.h",
"third_party/protobuf/src/google/protobuf/io/zero_copy_stream.cc",
"third_party/protobuf/src/google/protobuf/io/zero_copy_stream.h",
"third_party/protobuf/src/google/protobuf/io/zero_copy_stream_impl.cc",
"third_party/protobuf/src/google/protobuf/io/zero_copy_stream_impl.h",
"third_party/protobuf/src/google/protobuf/io/zero_copy_stream_impl_lite.cc",
"third_party/protobuf/src/google/protobuf/io/zero_copy_stream_impl_lite.h",
"third_party/protobuf/src/google/protobuf/map.h",
"third_party/protobuf/src/google/protobuf/map_entry_lite.h",
"third_party/protobuf/src/google/protobuf/map_field_lite.h",
"third_party/protobuf/src/google/protobuf/map_type_handler.h",
"third_party/protobuf/src/google/protobuf/message_lite.cc",
"third_party/protobuf/src/google/protobuf/message_lite.h",
"third_party/protobuf/src/google/protobuf/repeated_field.cc",
"third_party/protobuf/src/google/protobuf/repeated_field.h",
"third_party/protobuf/src/google/protobuf/stubs/bytestream.cc",
"third_party/protobuf/src/google/protobuf/stubs/bytestream.h",
"third_party/protobuf/src/google/protobuf/stubs/callback.h",
"third_party/protobuf/src/google/protobuf/stubs/casts.h",
"third_party/protobuf/src/google/protobuf/stubs/common.cc",
"third_party/protobuf/src/google/protobuf/stubs/common.h",
"third_party/protobuf/src/google/protobuf/stubs/fastmem.h",
"third_party/protobuf/src/google/protobuf/stubs/hash.h",
"third_party/protobuf/src/google/protobuf/stubs/int128.cc",
"third_party/protobuf/src/google/protobuf/stubs/int128.h",
"third_party/protobuf/src/google/protobuf/stubs/logging.h",
"third_party/protobuf/src/google/protobuf/stubs/macros.h",
"third_party/protobuf/src/google/protobuf/stubs/map_util.h",
"third_party/protobuf/src/google/protobuf/stubs/mutex.h",
"third_party/protobuf/src/google/protobuf/stubs/once.h",
"third_party/protobuf/src/google/protobuf/stubs/platform_macros.h",
"third_party/protobuf/src/google/protobuf/stubs/port.h",
"third_party/protobuf/src/google/protobuf/stubs/status.cc",
"third_party/protobuf/src/google/protobuf/stubs/status.h",
"third_party/protobuf/src/google/protobuf/stubs/status_macros.h",
"third_party/protobuf/src/google/protobuf/stubs/statusor.cc",
"third_party/protobuf/src/google/protobuf/stubs/statusor.h",
"third_party/protobuf/src/google/protobuf/stubs/stl_util.h",
"third_party/protobuf/src/google/protobuf/stubs/stringpiece.cc",
"third_party/protobuf/src/google/protobuf/stubs/stringpiece.h",
"third_party/protobuf/src/google/protobuf/stubs/stringprintf.cc",
"third_party/protobuf/src/google/protobuf/stubs/stringprintf.h",
"third_party/protobuf/src/google/protobuf/stubs/structurally_valid.cc",
"third_party/protobuf/src/google/protobuf/stubs/strutil.cc",
"third_party/protobuf/src/google/protobuf/stubs/strutil.h",
"third_party/protobuf/src/google/protobuf/stubs/template_util.h",
"third_party/protobuf/src/google/protobuf/stubs/time.cc",
"third_party/protobuf/src/google/protobuf/stubs/time.h",
"third_party/protobuf/src/google/protobuf/wire_format_lite.cc",
"third_party/protobuf/src/google/protobuf/wire_format_lite.h",
]
configs -= [ "//build/config/compiler:chromium_code" ]
configs += [
"//build/config/compiler:no_chromium_code",
":protobuf_config",
]
if (is_win) {
configs -= [ "//build/config/win:lean_and_mean" ]
}
public_configs = [ ":protobuf_gen_config" ]
}
# This target should be used only by the protoc compiler and by test targets.
source_set("protobuf_full") {
deps = [ ":protobuf_lite" ]
sources = [
"third_party/protobuf/src/google/protobuf/any.cc",
"third_party/protobuf/src/google/protobuf/any.h",
"third_party/protobuf/src/google/protobuf/any.pb.cc",
"third_party/protobuf/src/google/protobuf/any.pb.h",
"third_party/protobuf/src/google/protobuf/api.pb.cc",
"third_party/protobuf/src/google/protobuf/api.pb.h",
"third_party/protobuf/src/google/protobuf/compiler/importer.cc",
"third_party/protobuf/src/google/protobuf/compiler/importer.h",
"third_party/protobuf/src/google/protobuf/compiler/parser.cc",
"third_party/protobuf/src/google/protobuf/compiler/parser.h",
"third_party/protobuf/src/google/protobuf/descriptor.cc",
"third_party/protobuf/src/google/protobuf/descriptor.h",
"third_party/protobuf/src/google/protobuf/descriptor.pb.cc",
"third_party/protobuf/src/google/protobuf/descriptor.pb.h",
"third_party/protobuf/src/google/protobuf/descriptor_database.cc",
"third_party/protobuf/src/google/protobuf/descriptor_database.h",
"third_party/protobuf/src/google/protobuf/duration.pb.cc",
"third_party/protobuf/src/google/protobuf/duration.pb.h",
"third_party/protobuf/src/google/protobuf/dynamic_message.cc",
"third_party/protobuf/src/google/protobuf/dynamic_message.h",
"third_party/protobuf/src/google/protobuf/empty.pb.cc",
"third_party/protobuf/src/google/protobuf/empty.pb.h",
"third_party/protobuf/src/google/protobuf/extension_set_heavy.cc",
"third_party/protobuf/src/google/protobuf/field_mask.pb.cc",
"third_party/protobuf/src/google/protobuf/field_mask.pb.h",
"third_party/protobuf/src/google/protobuf/generated_enum_reflection.h",
"third_party/protobuf/src/google/protobuf/generated_message_reflection.cc",
"third_party/protobuf/src/google/protobuf/generated_message_reflection.h",
"third_party/protobuf/src/google/protobuf/io/gzip_stream.cc",
"third_party/protobuf/src/google/protobuf/io/gzip_stream.h",
"third_party/protobuf/src/google/protobuf/io/printer.cc",
"third_party/protobuf/src/google/protobuf/io/printer.h",
"third_party/protobuf/src/google/protobuf/io/tokenizer.cc",
"third_party/protobuf/src/google/protobuf/io/tokenizer.h",
"third_party/protobuf/src/google/protobuf/map_entry.h",
"third_party/protobuf/src/google/protobuf/map_field.cc",
"third_party/protobuf/src/google/protobuf/map_field.h",
"third_party/protobuf/src/google/protobuf/map_field_inl.h",
"third_party/protobuf/src/google/protobuf/message.cc",
"third_party/protobuf/src/google/protobuf/message.h",
"third_party/protobuf/src/google/protobuf/metadata.h",
"third_party/protobuf/src/google/protobuf/reflection.h",
"third_party/protobuf/src/google/protobuf/reflection_internal.h",
"third_party/protobuf/src/google/protobuf/reflection_ops.cc",
"third_party/protobuf/src/google/protobuf/reflection_ops.h",
"third_party/protobuf/src/google/protobuf/service.cc",
"third_party/protobuf/src/google/protobuf/service.h",
"third_party/protobuf/src/google/protobuf/source_context.pb.cc",
"third_party/protobuf/src/google/protobuf/source_context.pb.h",
"third_party/protobuf/src/google/protobuf/struct.pb.cc",
"third_party/protobuf/src/google/protobuf/struct.pb.h",
"third_party/protobuf/src/google/protobuf/stubs/mathlimits.cc",
"third_party/protobuf/src/google/protobuf/stubs/mathlimits.h",
"third_party/protobuf/src/google/protobuf/stubs/mathutil.h",
"third_party/protobuf/src/google/protobuf/stubs/substitute.cc",
"third_party/protobuf/src/google/protobuf/stubs/substitute.h",
"third_party/protobuf/src/google/protobuf/text_format.cc",
"third_party/protobuf/src/google/protobuf/text_format.h",
"third_party/protobuf/src/google/protobuf/timestamp.pb.cc",
"third_party/protobuf/src/google/protobuf/timestamp.pb.h",
"third_party/protobuf/src/google/protobuf/type.pb.cc",
"third_party/protobuf/src/google/protobuf/type.pb.h",
"third_party/protobuf/src/google/protobuf/unknown_field_set.cc",
"third_party/protobuf/src/google/protobuf/unknown_field_set.h",
"third_party/protobuf/src/google/protobuf/util/field_comparator.cc",
"third_party/protobuf/src/google/protobuf/util/field_comparator.h",
"third_party/protobuf/src/google/protobuf/util/field_mask_util.cc",
"third_party/protobuf/src/google/protobuf/util/field_mask_util.h",
"third_party/protobuf/src/google/protobuf/util/internal/constants.h",
"third_party/protobuf/src/google/protobuf/util/internal/datapiece.cc",
"third_party/protobuf/src/google/protobuf/util/internal/datapiece.h",
"third_party/protobuf/src/google/protobuf/util/internal/default_value_objectwriter.cc",
"third_party/protobuf/src/google/protobuf/util/internal/default_value_objectwriter.h",
"third_party/protobuf/src/google/protobuf/util/internal/error_listener.cc",
"third_party/protobuf/src/google/protobuf/util/internal/error_listener.h",
"third_party/protobuf/src/google/protobuf/util/internal/field_mask_utility.cc",
"third_party/protobuf/src/google/protobuf/util/internal/field_mask_utility.h",
"third_party/protobuf/src/google/protobuf/util/internal/json_escaping.cc",
"third_party/protobuf/src/google/protobuf/util/internal/json_escaping.h",
"third_party/protobuf/src/google/protobuf/util/internal/json_objectwriter.cc",
"third_party/protobuf/src/google/protobuf/util/internal/json_objectwriter.h",
"third_party/protobuf/src/google/protobuf/util/internal/json_stream_parser.cc",
"third_party/protobuf/src/google/protobuf/util/internal/json_stream_parser.h",
"third_party/protobuf/src/google/protobuf/util/internal/location_tracker.h",
"third_party/protobuf/src/google/protobuf/util/internal/object_location_tracker.h",
"third_party/protobuf/src/google/protobuf/util/internal/object_source.h",
"third_party/protobuf/src/google/protobuf/util/internal/object_writer.cc",
"third_party/protobuf/src/google/protobuf/util/internal/object_writer.h",
"third_party/protobuf/src/google/protobuf/util/internal/proto_writer.cc",
"third_party/protobuf/src/google/protobuf/util/internal/proto_writer.h",
"third_party/protobuf/src/google/protobuf/util/internal/protostream_objectsource.cc",
"third_party/protobuf/src/google/protobuf/util/internal/protostream_objectsource.h",
"third_party/protobuf/src/google/protobuf/util/internal/protostream_objectwriter.cc",
"third_party/protobuf/src/google/protobuf/util/internal/protostream_objectwriter.h",
"third_party/protobuf/src/google/protobuf/util/internal/structured_objectwriter.h",
"third_party/protobuf/src/google/protobuf/util/internal/type_info.cc",
"third_party/protobuf/src/google/protobuf/util/internal/type_info.h",
"third_party/protobuf/src/google/protobuf/util/internal/type_info_test_helper.cc",
"third_party/protobuf/src/google/protobuf/util/internal/type_info_test_helper.h",
"third_party/protobuf/src/google/protobuf/util/internal/utility.cc",
"third_party/protobuf/src/google/protobuf/util/internal/utility.h",
"third_party/protobuf/src/google/protobuf/util/json_util.cc",
"third_party/protobuf/src/google/protobuf/util/json_util.h",
"third_party/protobuf/src/google/protobuf/util/message_differencer.cc",
"third_party/protobuf/src/google/protobuf/util/message_differencer.h",
"third_party/protobuf/src/google/protobuf/util/time_util.cc",
"third_party/protobuf/src/google/protobuf/util/time_util.h",
"third_party/protobuf/src/google/protobuf/util/type_resolver.h",
"third_party/protobuf/src/google/protobuf/util/type_resolver_util.cc",
"third_party/protobuf/src/google/protobuf/util/type_resolver_util.h",
"third_party/protobuf/src/google/protobuf/wire_format.cc",
"third_party/protobuf/src/google/protobuf/wire_format.h",
"third_party/protobuf/src/google/protobuf/wrappers.pb.cc",
"third_party/protobuf/src/google/protobuf/wrappers.pb.h",
]
configs -= [ "//build/config/compiler:chromium_code" ]
configs += [
"//build/config/compiler:no_chromium_code",
":protobuf_config",
]
if (is_win) {
configs -= [ "//build/config/win:lean_and_mean" ]
}
public_configs = [ ":protobuf_gen_config" ]
}
if (current_toolchain == host_toolchain) {
source_set("protoc_lib") {
deps = [ ":protobuf_full" ]
sources = [
"third_party/protobuf/src/google/protobuf/compiler/code_generator.cc",
"third_party/protobuf/src/google/protobuf/compiler/code_generator.h",
"third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc",
"third_party/protobuf/src/google/protobuf/compiler/command_line_interface.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_enum.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_enum.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_enum_field.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_enum_field.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_extension.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_extension.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_field.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_field.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_file.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_file.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_generator.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_generator.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_helpers.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_helpers.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_map_field.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_map_field.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message_field.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message_field.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_message_layout_helper.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_options.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_padding_optimizer.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_padding_optimizer.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_primitive_field.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_primitive_field.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_service.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_service.h",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_string_field.cc",
"third_party/protobuf/src/google/protobuf/compiler/cpp/cpp_string_field.h",
"third_party/protobuf/src/google/protobuf/compiler/plugin.cc",
"third_party/protobuf/src/google/protobuf/compiler/plugin.h",
"third_party/protobuf/src/google/protobuf/compiler/plugin.pb.cc",
"third_party/protobuf/src/google/protobuf/compiler/plugin.pb.h",
"third_party/protobuf/src/google/protobuf/compiler/subprocess.cc",
"third_party/protobuf/src/google/protobuf/compiler/subprocess.h",
"third_party/protobuf/src/google/protobuf/compiler/zip_writer.cc",
"third_party/protobuf/src/google/protobuf/compiler/zip_writer.h",
]
configs -= [ "//build/config/compiler:chromium_code" ]
configs += [
"//build/config/compiler:no_chromium_code",
":protobuf_config",
]
if (is_win) {
configs -= [ "//build/config/win:lean_and_mean" ]
}
public_configs = [ ":protobuf_gen_config" ]
}
executable("protoc") {
deps = [
":protoc_lib",
"//build/win:default_exe_manifest",
]
sources = [ "src/protobuf/protobuf-compiler-main.cc" ]
configs -= [ "//build/config/compiler:chromium_code" ]
configs += [ "//build/config/compiler:no_chromium_code" ]
}
} # host_toolchain
v8_component("v8_libperfetto") {
configs = [ ":v8_tracing_config" ]
public_configs = [ "//third_party/perfetto/gn:public_config" ]
deps = [
"//third_party/perfetto/src/trace_processor:storage_minimal",
"//third_party/perfetto/src/tracing/core",
# TODO(skyostil): Support non-POSIX platforms.
"//third_party/perfetto/protos/perfetto/config:cpp",
"//third_party/perfetto/protos/perfetto/trace/track_event:zero",
"//third_party/perfetto/src/tracing:in_process_backend",
"//third_party/perfetto/src/tracing:platform_impl",
]
public_deps = [
"//third_party/perfetto/include/perfetto/trace_processor",
"//third_party/perfetto/src/trace_processor:export_json",
"//third_party/perfetto/src/tracing:client_api",
]
}
} # if (!build_with_chromium && v8_use_perfetto)