v8/BUILD.gn

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

6190 lines
202 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
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 -DSYSTEM_INSTRUMENTATION. Enables OS-dependent event tracing
v8_enable_system_instrumentation = false
# 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_HANDLE_ZAPPING.
v8_enable_handle_zapping = true
# 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).
v8_enable_snapshot_code_comments = false
# 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 = ""
# 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 = ""
# Sets -dV8_ATOMIC_MARKING_STATE
v8_enable_atomic_marking_state = ""
# Controls the default values of v8_enable_atomic_object_field_writes and
# v8_enable_concurrent_marking_state. See the default setting code below.
v8_enable_concurrent_marking = true
[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-log-builtins flag.
# For Chrome, the invocation might look like this:
# chrome --no-sandbox --disable-extensions
# --js-flags="--turbo-profiling-log-builtins --logfile=path/to/v8.log"
# "http://localhost/test-suite"
# 3. Optionally repeat step 2 for additional workloads, and concatenate all of
# the resulting log files into a single file.
# 4. Build again with v8_builtins_profiling_log_file set to the file created
# in steps 2-3.
v8_builtins_profiling_log_file = ""
# 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 = ""
# 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))
# Temporary flag to allow embedders to update their microtasks scopes
# while rolling in a new version of V8.
v8_check_microtasks_scopes_consistency = ""
# Enable mitigations for executing untrusted code.
# Disabled by default on ia32 due to conflicting requirements with embedded
# builtins. Enabled by default on Android since it doesn't support
# site-isolation in Chrome and on simulator builds which test code generation
# on these platforms.
v8_untrusted_code_mitigations =
v8_current_cpu != "x86" && (is_android || target_is_simulator)
# Enable minor mark compact.
v8_enable_minor_mc = true
# 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
# Disable all snapshot compression.
v8_enable_snapshot_compression = true
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.
v8_control_flow_integrity = false
# Enable object names in cppgc for debug purposes.
cppgc_enable_object_names = false
# Enable heap reservation of size 4GB. Only possible for 64bit archs.
cppgc_enable_caged_heap = v8_current_cpu == "x64" || v8_current_cpu == "arm64"
# Enable young generation in cppgc.
cppgc_enable_young_generation = false
# Enable V8 zone compression experimental feature.
# Sets -DV8_COMPRESS_ZONES.
v8_enable_zone_compression = ""
# Enable V8 heap sandbox experimental feature.
# Sets -DV8_HEAP_SANDBOX.
v8_enable_heap_sandbox = ""
# Experimental feature for collecting per-class zone memory stats.
# Requires use_rtti = true
v8_enable_precise_zone_stats = false
# Experimental feature for always keeping prototypes in dict/"slow" mode
# Sets -DV8_DICT_MODE_PROTOTYPES
v8_dict_mode_prototypes = 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
}
# Derived defaults.
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 == "") {
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_check_microtasks_scopes_consistency == "") {
v8_check_microtasks_scopes_consistency =
v8_enable_debugging_features || dcheck_always_on
}
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"
}
if (v8_enable_pointer_compression_shared_cage == "") {
v8_enable_pointer_compression_shared_cage = v8_enable_pointer_compression
}
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_heap_sandbox == "") {
v8_enable_heap_sandbox = false
}
if (v8_enable_short_builtin_calls == "") {
v8_enable_short_builtin_calls =
v8_current_cpu == "x64" || (!is_android && v8_current_cpu == "arm64")
}
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_atomic_marking_state == "") {
v8_enable_atomic_marking_state = v8_enable_concurrent_marking
}
assert(!v8_enable_concurrent_marking || v8_enable_atomic_object_field_writes,
"Concurrent marking requires atomic object field writes.")
assert(!v8_enable_concurrent_marking || v8_enable_atomic_marking_state,
"Concurrent marking requires atomic marking state.")
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.")
# 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
v8_enable_pointer_compression_shared_cage = v8_enable_pointer_compression
}
if (v8_enable_short_builtin_calls && !v8_enable_pointer_compression) {
# Disable short calls when pointer compression is not enabled.
v8_enable_short_builtin_calls = false
}
if (v8_enable_shared_ro_heap == "") {
v8_enable_shared_ro_heap = !v8_enable_pointer_compression
}
assert(!v8_disable_write_barriers || v8_enable_single_generation,
"Disabling write barriers works only with single generation")
assert(v8_current_cpu != "x86" || !v8_untrusted_code_mitigations,
"Untrusted code mitigations are unsupported on ia32")
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")
[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
if (v8_enable_shared_ro_heap && v8_enable_pointer_compression) {
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
}
assert(!v8_use_multi_snapshots || !v8_control_flow_integrity,
"Control-flow integrity does not support multisnapshots")
assert(!v8_enable_heap_sandbox || v8_enable_pointer_compression,
"V8 Heap Sandbox requires pointer compression")
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_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",
"CppGC caged heap requires 64bit platforms")
assert(!cppgc_enable_young_generation || cppgc_enable_caged_heap,
"Young generation in CppGC requires caged heap")
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)")
}
[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
assert(!v8_enable_conservative_stack_scanning || v8_enable_single_generation,
"Conservative stack scanning requires single generation")
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" ]
}
}
# 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" ]
}
}
# 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",
"V8_31BIT_SMIS_ON_64BIT_ARCH",
"V8_COMPRESS_ZONES",
"V8_HEAP_SANDBOX",
"V8_DEPRECATION_WARNINGS",
"V8_IMMINENT_DEPRECATION_WARNINGS",
"V8_NO_ARGUMENTS_ADAPTOR",
"V8_USE_PERFETTO",
]
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" ]
}
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" ]
}
if (v8_enable_heap_sandbox) {
enabled_external_v8_defines += [ "V8_HEAP_SANDBOX" ]
}
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" ]
}
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",
]
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" ]
}
if (cppgc_enable_young_generation) {
enabled_external_cppgc_defines += [ "CPPGC_YOUNG_GENERATION" ]
}
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 (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}" ]
assert(
!v8_enable_raw_heap_snapshots,
"This flag is deprecated and is now available through the inspector interface as an argument to profiler's method `takeHeapSnapshot`. Consider using blink's flag `enable_additional_blink_object_names` to get better naming of internal objects.")
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_minor_mc) {
defines += [ "ENABLE_MINOR_MC" ]
}
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" ]
}
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_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_atomic_marking_state) {
defines += [ "V8_ATOMIC_MARKING_STATE" ]
}
if (v8_enable_lazy_source_positions) {
defines += [ "V8_ENABLE_LAZY_SOURCE_POSITIONS" ]
}
if (v8_check_microtasks_scopes_consistency) {
defines += [ "V8_CHECK_MICROTASKS_SCOPES_CONSISTENCY" ]
}
if (v8_use_multi_snapshots) {
defines += [ "V8_MULTI_SNAPSHOTS" ]
}
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" ]
}
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_dict_mode_prototypes) {
defines += [ "V8_DICT_MODE_PROTOTYPES" ]
}
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_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" ]
}
}
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(jochen): 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" ]
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) {
# TODO(v8:10026): Enable this in src/build.
if (current_cpu == "arm64") {
cflags += [ "-mbranch-protection=standard" ]
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/mipsel simulators.
if (target_is_simulator &&
(v8_current_cpu == "mipsel" || v8_current_cpu == "mips64el")) {
defines += [ "_MIPS_TARGET_SIMULATOR" ]
}
if (v8_current_cpu == "mipsel" || v8_current_cpu == "mips") {
defines += [ "V8_TARGET_ARCH_MIPS" ]
if (v8_can_use_fpu_instructions) {
defines += [ "CAN_USE_FPU_INSTRUCTIONS" ]
}
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_MIPS32R6",
"FPU_MODE_FP64",
]
if (mips_use_msa) {
defines += [ "_MIPS_MSA" ]
}
} else if (mips_arch_variant == "r2") {
defines += [ "_MIPS_ARCH_MIPS32R2" ]
if (mips_fpu_mode == "fp64") {
defines += [ "FPU_MODE_FP64" ]
} else if (mips_fpu_mode == "fpxx") {
defines += [ "FPU_MODE_FPXX" ]
} else if (mips_fpu_mode == "fp32") {
defines += [ "FPU_MODE_FP32" ]
}
} else if (mips_arch_variant == "r1") {
defines += [ "FPU_MODE_FP32" ]
}
# TODO(jochen): Add support for mips_arch_variant rx and loongson.
}
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" ]
}
}
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" ]
#FIXME: Temporarily use MIPS macro for the building.
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_MACOSX" ]
} else if (target_os == "win") {
defines += [ "V8_HAVE_TARGET_OS" ]
defines += [ "V8_TARGET_OS_WIN" ]
}
# TODO(jochen): Support v8_enable_prof on Windows.
# TODO(jochen): 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" ]
}
} else if (dcheck_always_on) {
defines += [ "DEBUG" ]
}
if (v8_enable_verify_csa) {
defines += [ "ENABLE_VERIFY_CSA" ]
}
if (!v8_untrusted_code_mitigations) {
defines += [ "DISABLE_UNTRUSTED_CODE_MITIGATIONS" ]
}
if (v8_no_inline) {
if (is_win) {
cflags += [ "/Ob0" ]
} else {
cflags += [
"-fno-inline-functions",
"-fno-inline",
]
}
}
if (is_clang) {
cflags += [ "-Wmissing-field-initializers" ]
if (v8_current_cpu != "mips" && v8_current_cpu != "mipsel") {
# We exclude MIPS because the IsMipsArchVariant macro causes trouble.
cflags += [ "-Wunreachable-code" ]
}
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"
}
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",
]
}
# 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_optimize") {
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",
]
}
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) {
# We don't support side-by-side snapshots on Android within Chromium.
assert(!v8_use_multi_snapshots)
deps = [ "//v8" ]
renaming_sources = [ "$root_out_dir/snapshot_blob.bin" ]
if (current_cpu == "arm" || current_cpu == "x86" ||
current_cpu == "mipsel") {
renaming_destinations = [ "snapshot_blob_32.bin" ]
} else {
renaming_destinations = [ "snapshot_blob_64.bin" ]
}
disable_compression = true
}
}
}
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 = [
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/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-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/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",
[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.h",
"src/objects/primitive-heap-object-inl.h",
"src/objects/scope-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/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-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-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-unshift.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-dynamic-check-maps.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-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-values.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/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-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-regexp-string-iterator.tq",
"src/objects/js-regexp.tq",
"src/objects/js-weak-refs.tq",
"src/objects/literal-objects.tq",
"src/objects/map.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/stack-frame-info.tq",
"src/objects/string.tq",
"src/objects/struct.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",
"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-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"
files = [
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/bit-fields.h",
"$target_gen_dir/torque-generated/builtin-definitions.h",
"$target_gen_dir/torque-generated/class-debug-readers.cc",
"$target_gen_dir/torque-generated/class-debug-readers.h",
"$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/csa-types.h",
"$target_gen_dir/torque-generated/debug-macros.cc",
"$target_gen_dir/torque-generated/debug-macros.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/enum-verifiers.cc",
"$target_gen_dir/torque-generated/exported-macros-assembler.cc",
"$target_gen_dir/torque-generated/exported-macros-assembler.h",
"$target_gen_dir/torque-generated/factory.cc",
"$target_gen_dir/torque-generated/factory.inc",
"$target_gen_dir/torque-generated/field-offsets.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/instance-types.h",
"$target_gen_dir/torque-generated/interface-descriptors.inc",
"$target_gen_dir/torque-generated/objects-body-descriptors-inl.inc",
"$target_gen_dir/torque-generated/objects-printer.cc",
]
outputs = []
foreach(file, files) {
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
outputs += [ string_replace(file,
"$target_gen_dir/torque-generated",
destination_folder) ]
}
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 += [
[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",
"$target_gen_dir/torque-generated/$filetq-inl.inc",
"$target_gen_dir/torque-generated/$filetq.cc",
"$target_gen_dir/torque-generated/$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",
]
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-log-file",
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
]
}
[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-rewrite-far-jumps",
"--no-turbo-verify-allocation",
]
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
}
}
if (v8_use_multi_snapshots) {
run_mksnapshot("trusted") {
args = [ "--no-untrusted-code-mitigations" ]
embedded_variant = "Trusted"
}
if (emit_builtins_as_inline_asm) {
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
asm_to_inline_asm("trusted") {
args = []
}
}
}
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\"",
"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_marking_state=$v8_enable_atomic_marking_state",
"v8_enable_atomic_object_field_writes=" +
"$v8_enable_atomic_object_field_writes",
"v8_enable_concurrent_marking=$v8_enable_concurrent_marking",
"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_pointer_compression=$v8_enable_pointer_compression",
"v8_enable_webassembly=$v8_enable_webassembly",
"v8_control_flow_integrity=$v8_control_flow_integrity",
"v8_target_cpu=\"$v8_target_cpu\"",
]
if (v8_current_cpu == "mips" || v8_current_cpu == "mipsel" ||
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 = []
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" ]
if (v8_use_multi_snapshots) {
public_deps += [ ":run_mksnapshot_trusted" ]
if (emit_builtins_as_inline_asm) {
deps += [ ":asm_to_inline_asm_trusted" ]
sources += [ "$target_gen_dir/embedded_trusted.cc" ]
} else {
sources += [ "$target_gen_dir/embedded_trusted.S" ]
}
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
}
} else {
# Also top-level visibility targets can depend on this.
visibility += [ "//:gn_visibility" ]
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-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-debug-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-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-sharedarraybuffer-gen.cc",
"src/builtins/builtins-string-gen.cc",
"src/builtins/builtins-string-gen.h",
"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",
]
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(arch:ia32) ###
"src/builtins/ia32/builtins-ia32.cc",
]
} else if (v8_current_cpu == "x64") {
sources += [
### gcmole(arch:x64) ###
"src/builtins/x64/builtins-x64.cc",
]
} else if (v8_current_cpu == "arm") {
sources += [
### gcmole(arch:arm) ###
"src/builtins/arm/builtins-arm.cc",
]
} else if (v8_current_cpu == "arm64") {
sources += [
### gcmole(arch:arm64) ###
"src/builtins/arm64/builtins-arm64.cc",
]
} else if (v8_current_cpu == "mips" || v8_current_cpu == "mipsel") {
sources += [
### gcmole(arch:mipsel) ###
"src/builtins/mips/builtins-mips.cc",
]
} else if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
sources += [
### gcmole(arch:mips64el) ###
"src/builtins/mips64/builtins-mips64.cc",
]
} else if (v8_current_cpu == "ppc") {
sources += [
### gcmole(arch:ppc) ###
"src/builtins/ppc/builtins-ppc.cc",
]
} else if (v8_current_cpu == "ppc64") {
sources += [
### gcmole(arch:ppc64) ###
"src/builtins/ppc/builtins-ppc.cc",
]
} else if (v8_current_cpu == "s390" || v8_current_cpu == "s390x") {
sources += [
### gcmole(arch:s390) ###
"src/builtins/s390/builtins-s390.cc",
]
} else if (v8_current_cpu == "riscv64") {
sources += [
### gcmole(arch:riscv64) ###
"src/builtins/riscv64/builtins-riscv64.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",
]
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 = [
"include/v8-cppgc.h",
"include/v8-fast-api-calls.h",
"include/v8-internal.h",
"include/v8-profiler.h",
"include/v8-util.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/cctest:*",
"test/unittests:*",
"tools/debug_helper/:*",
]
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 = [ ":*" ]
configs = [ ":internal_config" ]
sources = [
"src/flags/flag-definitions.h",
"src/flags/flags.h",
]
deps = [ ":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",
"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.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-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/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",
"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/optimized-compilation-info.h",
"src/codegen/pending-optimization-table.h",
"src/codegen/register-arch.h",
"src/codegen/register-configuration.h",
"src/codegen/register.h",
"src/codegen/reglist.h",
"src/codegen/reloc-info.h",
"src/codegen/safepoint-table.h",
"src/codegen/signature.h",
"src/codegen/source-position-table.h",
"src/codegen/source-position.h",
"src/codegen/string-constants.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/external-pointer-inl.h",
"src/common/external-pointer.h",
"src/common/message-template.h",
"src/common/ptr-compr-inl.h",
"src/common/ptr-compr.h",
"src/compiler-dispatcher/compiler-dispatcher.h",
"src/compiler-dispatcher/optimizing-compile-dispatcher.h",
"src/compiler/all-nodes.h",
"src/compiler/allocation-builder-inl.h",
"src/compiler/allocation-builder.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",
"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/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/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/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-heap-copy-reducer.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/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/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/scheduled-machine-lowering.h",
"src/compiler/scheduler.h",
"src/compiler/select-lowering.h",
"src/compiler/serializer-for-background-compilation.h",
"src/compiler/serializer-hints.h",
"src/compiler/simd-scalar-lowering.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/type-cache.h",
"src/compiler/type-narrowing-reducer.h",
"src/compiler/typed-optimization.h",
"src/compiler/typer.h",
"src/compiler/types.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-type-profile.h",
"src/debug/debug.h",
"src/debug/interface-types.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/execution.h",
"src/execution/external-pointer-table.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.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/runtime-profiler.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/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.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/heap/allocation-observer.h",
"src/heap/allocation-stats.h",
"src/heap/array-buffer-sweeper.h",
"src/heap/barrier.h",
"src/heap/base-space.h",
"src/heap/basic-memory-chunk.h",
"src/heap/code-object-registry.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",
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/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.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-idle-time-handler.h",
"src/heap/gc-tracer.h",
"src/heap/heap-controller.h",
"src/heap/heap-inl.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/item-parallel-job.h",
"src/heap/large-spaces.h",
"src/heap/list.h",
"src/heap/local-allocator-inl.h",
"src/heap/local-allocator.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.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/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/weak-object-worklists.h",
"src/heap/worklist.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",
"src/logging/counters-inl.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-inl.h",
"src/logging/log-utils.h",
"src/logging/log.h",
"src/logging/metrics.h",
"src/logging/tracing-flags.h",
"src/numbers/bignum-dtoa.h",
"src/numbers/bignum.h",
"src/numbers/cached-powers.h",
"src/numbers/conversions-inl.h",
"src/numbers/conversions.h",
"src/numbers/diy-fp.h",
"src/numbers/double.h",
"src/numbers/dtoa.h",
"src/numbers/fast-dtoa.h",
"src/numbers/fixed-dtoa.h",
"src/numbers/hash-seed-inl.h",
"src/numbers/math-random.h",
"src/numbers/strtod.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/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",
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-collection-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-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-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.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",
"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/objects-body-descriptors-inl.h",
"src/objects/objects-body-descriptors.h",
"src/objects/objects-inl.h",
"src/objects/objects.h",
"src/objects/oddball-inl.h",
"src/objects/oddball.h",
"src/objects/ordered-hash-table-inl.h",
"src/objects/ordered-hash-table.h",
"src/objects/osr-optimized-code-cache-inl.h",
"src/objects/osr-optimized-code-cache.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.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/slots-atomic-inl.h",
"src/objects/slots-inl.h",
"src/objects/slots.h",
"src/objects/source-text-module.h",
"src/objects/stack-frame-info-inl.h",
"src/objects/stack-frame-info.h",
"src/objects/string-comparator.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",
"src/objects/type-hints.h",
"src/objects/value-serializer.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/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.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/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/regexp/experimental/experimental-bytecode.h",
"src/regexp/experimental/experimental-compiler.h",
"src/regexp/experimental/experimental-interpreter.h",
"src/regexp/experimental/experimental.h",
"src/regexp/property-sequences.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-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/runtime/runtime-utils.h",
"src/runtime/runtime.h",
"src/sanitizer/asan.h",
"src/sanitizer/lsan-page-allocator.h",
"src/sanitizer/msan.h",
"src/sanitizer/tsan.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.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.h",
"src/snapshot/snapshot-compression.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/third_party/siphash/halfsiphash.h",
"src/third_party/utf8-decoder/utf8-decoder.h",
"src/tracing/trace-event.h",
"src/tracing/traced-value.h",
"src/tracing/tracing-category-observer.h",
"src/trap-handler/trap-handler-internal.h",
"src/trap-handler/trap-handler.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/identity-map.h",
"src/utils/locked-queue-inl.h",
"src/utils/locked-queue.h",
"src/utils/memcopy.h",
"src/utils/ostreams.h",
"src/utils/pointer-with-payload.h",
"src/utils/scoped-list.h",
"src/utils/utils-inl.h",
"src/utils/utils.h",
"src/utils/vector.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_use_perfetto) {
sources -= [ "//base/trace_event/common/trace_event_common.h" ]
}
if (v8_enable_webassembly) {
sources += [
"src/asmjs/asm-js.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.h",
"src/debug/debug-wasm-objects-inl.h",
"src/debug/debug-wasm-objects.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/code-space-access.h",
"src/wasm/compilation-environment.h",
"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.h",
"src/wasm/module-instantiate.h",
"src/wasm/object-access.h",
"src/wasm/signature-map.h",
"src/wasm/simd-shuffle.h",
"src/wasm/streaming-decoder.h",
"src/wasm/struct-types.h",
"src/wasm/value-type.h",
"src/wasm/wasm-arguments.h",
"src/wasm/wasm-code-manager.h",
"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-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.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_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-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",
"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_current_cpu == "x86") {
sources += [ ### gcmole(arch: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/macro-assembler-ia32.h",
"src/codegen/ia32/register-ia32.h",
"src/codegen/ia32/sse-instr.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(arch:x64) ###
"src/baseline/x64/baseline-assembler-x64-inl.h",
"src/baseline/x64/baseline-compiler-x64-inl.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/macro-assembler-x64.h",
"src/codegen/x64/register-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",
]
# 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" ]
}
if (is_win) {
sources += [
"src/diagnostics/unwinding-info-win64.h",
"src/trap-handler/handler-inside-win.h",
]
}
} else if (v8_current_cpu == "arm") {
sources += [ ### gcmole(arch: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/macro-assembler-arm.h",
"src/codegen/arm/register-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(arch: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/macro-assembler-arm64-inl.h",
"src/codegen/arm64/macro-assembler-arm64.h",
"src/codegen/arm64/register-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" ]
}
if (current_cpu == "arm64" && is_mac) {
sources += [ "src/trap-handler/handler-inside-posix.h" ]
}
if (is_win) {
sources += [ "src/diagnostics/unwinding-info-win64.h" ]
}
} else if (v8_current_cpu == "mips" || v8_current_cpu == "mipsel") {
sources += [ ### gcmole(arch:mipsel) ###
"src/baseline/mips/baseline-assembler-mips-inl.h",
"src/baseline/mips/baseline-compiler-mips-inl.h",
"src/codegen/mips/assembler-mips-inl.h",
"src/codegen/mips/assembler-mips.h",
"src/codegen/mips/constants-mips.h",
"src/codegen/mips/macro-assembler-mips.h",
"src/codegen/mips/register-mips.h",
"src/compiler/backend/mips/instruction-codes-mips.h",
"src/execution/mips/frame-constants-mips.h",
"src/execution/mips/simulator-mips.h",
"src/regexp/mips/regexp-macro-assembler-mips.h",
"src/wasm/baseline/mips/liftoff-assembler-mips.h",
]
} else if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
sources += [ ### gcmole(arch: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/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 == "ppc") {
sources += [ ### gcmole(arch:ppc) ###
"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/macro-assembler-ppc.h",
"src/codegen/ppc/register-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(arch: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/macro-assembler-ppc.h",
"src/codegen/ppc/register-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(arch: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/macro-assembler-s390.h",
"src/codegen/s390/register-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(arch:riscv64) ###
"src/codegen/riscv64/assembler-riscv64-inl.h",
"src/codegen/riscv64/assembler-riscv64.h",
"src/codegen/riscv64/constants-riscv64.h",
"src/codegen/riscv64/macro-assembler-riscv64.h",
"src/codegen/riscv64/register-riscv64.h",
"src/compiler/backend/riscv64/instruction-codes-riscv64.h",
"src/execution/riscv64/frame-constants-riscv64.h",
"src/execution/riscv64/simulator-riscv64.h",
"src/regexp/riscv64/regexp-macro-assembler-riscv64.h",
"src/wasm/baseline/riscv64/liftoff-assembler-riscv64.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",
":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/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",
"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/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/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-heap-copy-reducer.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/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/scheduled-machine-lowering.cc",
"src/compiler/scheduler.cc",
"src/compiler/select-lowering.cc",
"src/compiler/serializer-for-background-compilation.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",
]
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/simd-scalar-lowering.cc",
"src/compiler/wasm-compiler.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_optimize" ]
} 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" ]
}
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-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-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-sharedarraybuffer.cc",
"src/builtins/builtins-string.cc",
"src/builtins/builtins-symbol.cc",
"src/builtins/builtins-trace.cc",
"src/builtins/builtins-typed-array.cc",
"src/builtins/builtins-weak-refs.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/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/string-constants.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/compiler-dispatcher/compiler-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-type-profile.cc",
"src/debug/debug.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/execution.cc",
"src/execution/external-pointer-table.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/runtime-profiler.cc",
"src/execution/simulator-base.cc",
"src/execution/stack-guard.cc",
"src/execution/thread-id.cc",
"src/execution/thread-local-top.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/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-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/unified-heap-marking-verifier.cc",
"src/heap/cppgc-js/unified-heap-marking-visitor.cc",
"src/heap/embedder-tracing.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-controller.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/item-parallel-job.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/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/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-utils.cc",
"src/logging/log.cc",
"src/logging/metrics.cc",
"src/logging/tracing-flags.cc",
"src/numbers/bignum-dtoa.cc",
"src/numbers/bignum.cc",
"src/numbers/cached-powers.cc",
"src/numbers/conversions.cc",
"src/numbers/diy-fp.cc",
"src/numbers/dtoa.cc",
"src/numbers/fast-dtoa.cc",
"src/numbers/fixed-dtoa.cc",
"src/numbers/math-random.cc",
"src/numbers/strtod.cc",
"src/objects/backing-store.cc",
"src/objects/bigint.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-break-iterator.cc",
"src/objects/js-collator.cc",
"src/objects/js-date-time-format.cc",
"src/objects/js-display-names.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-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/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/objects.cc",
"src/objects/ordered-hash-table.cc",
"src/objects/osr-optimized-code-cache.cc",
"src/objects/property-descriptor.cc",
"src/objects/property.cc",
"src/objects/scope-info.cc",
"src/objects/shared-function-info.cc",
"src/objects/source-text-module.cc",
"src/objects/stack-frame-info.cc",
"src/objects/string-comparator.cc",
"src/objects/string-table.cc",
"src/objects/string.cc",
"src/objects/swiss-name-dictionary.cc",
"src/objects/synthetic-module.cc",
"src/objects/tagged-impl.cc",
"src/objects/template-objects.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/regexp/experimental/experimental-bytecode.cc",
"src/regexp/experimental/experimental-compiler.cc",
"src/regexp/experimental/experimental-interpreter.cc",
"src/regexp/experimental/experimental.cc",
"src/regexp/property-sequences.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-strings.cc",
"src/runtime/runtime-symbol.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",
"src/sanitizer/lsan-page-allocator.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/snapshot-compression.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/third_party/siphash/halfsiphash.cc",
"src/tracing/trace-event.cc",
"src/tracing/traced-value.cc",
"src/tracing/tracing-category-observer.cc",
"src/trap-handler/handler-inside.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
"src/trap-handler/handler-outside.cc",
"src/trap-handler/handler-shared.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_webassembly) {
sources += [
"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/wasm/baseline/liftoff-assembler.cc",
"src/wasm/baseline/liftoff-compiler.cc",
"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/signature-map.cc",
"src/wasm/simd-shuffle.cc",
"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-engine.cc",
"src/wasm/wasm-external-refs.cc",
"src/wasm/wasm-features.cc",
"src/wasm/wasm-import-wrapper-cache.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 += v8_third_party_heap_files
} 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_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")
sources += check_header_includes_sources
}
if (v8_current_cpu == "x86") {
sources += [ ### gcmole(arch:ia32) ###
"src/codegen/ia32/assembler-ia32.cc",
"src/codegen/ia32/cpu-ia32.cc",
"src/codegen/ia32/interface-descriptors-ia32.cc",
"src/codegen/ia32/macro-assembler-ia32.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/debug/ia32/debug-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(arch:x64) ###
"src/codegen/x64/assembler-x64.cc",
"src/codegen/x64/cpu-x64.cc",
"src/codegen/x64/interface-descriptors-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/debug/x64/debug-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",
]
# 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",
]
}
if (is_win) {
sources += [
"src/diagnostics/unwinding-info-win64.cc",
"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(arch:arm) ###
"src/codegen/arm/assembler-arm.cc",
"src/codegen/arm/constants-arm.cc",
"src/codegen/arm/cpu-arm.cc",
"src/codegen/arm/interface-descriptors-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/debug/arm/debug-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(arch: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/interface-descriptors-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/debug/arm64/debug-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",
]
if (current_cpu == "arm64" && is_mac) {
sources += [
"src/trap-handler/handler-inside-posix.cc",
"src/trap-handler/handler-outside-posix.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 == "mips" || v8_current_cpu == "mipsel") {
sources += [ ### gcmole(arch:mipsel) ###
"src/codegen/mips/assembler-mips.cc",
"src/codegen/mips/constants-mips.cc",
"src/codegen/mips/cpu-mips.cc",
"src/codegen/mips/interface-descriptors-mips.cc",
"src/codegen/mips/macro-assembler-mips.cc",
"src/compiler/backend/mips/code-generator-mips.cc",
"src/compiler/backend/mips/instruction-scheduler-mips.cc",
"src/compiler/backend/mips/instruction-selector-mips.cc",
"src/debug/mips/debug-mips.cc",
"src/deoptimizer/mips/deoptimizer-mips.cc",
"src/diagnostics/mips/disasm-mips.cc",
"src/diagnostics/mips/unwinder-mips.cc",
"src/execution/mips/frame-constants-mips.cc",
"src/execution/mips/simulator-mips.cc",
"src/regexp/mips/regexp-macro-assembler-mips.cc",
]
} else if (v8_current_cpu == "mips64" || v8_current_cpu == "mips64el") {
sources += [ ### gcmole(arch: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.cc",
"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/debug/mips64/debug-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 == "ppc") {
sources += [ ### gcmole(arch:ppc) ###
"src/codegen/ppc/assembler-ppc.cc",
"src/codegen/ppc/constants-ppc.cc",
"src/codegen/ppc/cpu-ppc.cc",
"src/codegen/ppc/interface-descriptors-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/debug/ppc/debug-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(arch:ppc64) ###
"src/codegen/ppc/assembler-ppc.cc",
"src/codegen/ppc/constants-ppc.cc",
"src/codegen/ppc/cpu-ppc.cc",
"src/codegen/ppc/interface-descriptors-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/debug/ppc/debug-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(arch:s390) ###
"src/codegen/s390/assembler-s390.cc",
"src/codegen/s390/constants-s390.cc",
"src/codegen/s390/cpu-s390.cc",
"src/codegen/s390/interface-descriptors-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/debug/s390/debug-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(arch:riscv64) ###
"src/codegen/riscv64/assembler-riscv64.cc",
"src/codegen/riscv64/constants-riscv64.cc",
"src/codegen/riscv64/cpu-riscv64.cc",
"src/codegen/riscv64/interface-descriptors-riscv64.cc",
"src/codegen/riscv64/macro-assembler-riscv64.cc",
"src/compiler/backend/riscv64/code-generator-riscv64.cc",
"src/compiler/backend/riscv64/instruction-scheduler-riscv64.cc",
"src/compiler/backend/riscv64/instruction-selector-riscv64.cc",
"src/debug/riscv64/debug-riscv64.cc",
"src/deoptimizer/riscv64/deoptimizer-riscv64.cc",
"src/diagnostics/riscv64/disasm-riscv64.cc",
"src/diagnostics/riscv64/unwinder-riscv64.cc",
"src/execution/riscv64/frame-constants-riscv64.cc",
"src/execution/riscv64/simulator-riscv64.cc",
"src/regexp/riscv64/regexp-macro-assembler-riscv64.cc",
]
}
# Architecture independent but platform-specific sources
if (is_win) {
if (v8_enable_system_instrumentation) {
sources += [
"src/diagnostics/system-jit-metadata-win.h",
"src/diagnostics/system-jit-win.cc",
"src/diagnostics/system-jit-win.h",
]
}
}
configs = [
":internal_config",
":cppgc_base_config",
]
deps = [
":torque_generated_definitions",
":v8_cppgc_shared",
":v8_headers",
":v8_libbase",
":v8_shared_internal_headers",
":v8_tracing",
":v8_version",
"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-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",
]
}
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 == "mips" || v8_current_cpu == "mipsel" ||
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") {
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_source_set("torque_base") {
visibility = [ ":*" ] # Only targets in this file can depend on this.
sources = [
"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/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/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_optimize" ]
}
}
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",
"src/base/atomicops_internals_atomicword_compat.h",
"src/base/atomicops_internals_portable.h",
"src/base/atomicops_internals_std.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/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/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.cc",
"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/lsan.h",
"src/base/macros.h",
"src/base/memory.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/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/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/small-vector.h",
"src/base/sys-info.cc",
"src/base/sys-info.h",
"src/base/template-utils.h",
"src/base/timezone-cache.h",
"src/base/type-traits.h",
"src/base/utils/random-number-generator.cc",
"src/base/utils/random-number-generator.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",
]
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-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/pkg/zx" ]
} else if (is_mac || is_ios) {
sources += [
"src/base/debug/stack_trace_posix.cc",
"src/base/platform/platform-macos.cc",
]
} else if (is_win) {
# TODO(jochen): 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",
]
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) {
libs += [ "advapi32.lib" ] # Needed for TraceLoggingProvider.h
}
data_deps += [ "//build/win:runtime_libs" ]
}
if (v8_current_cpu == "mips" || 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" ||
v8_current_cpu == "mips")) {
# Special UBSan 32-bit requirement.
sources += [ "src/base/ubsan.cc" ]
}
if (v8_current_cpu == "riscv64") {
libs += [ "atomic" ]
}
if (is_tsan && !build_with_chromium) {
data += [ "tools/sanitizers/tsan_suppressions.txt" ]
# llvm-symbolizer uses libstdc++ from the clang package.
data += [ "//third_party/llvm-build/Release+Asserts/lib/libstdc++.so.6" ]
}
# TODO(jochen): Add support for qnx, freebsd, openbsd, netbsd, and solaris.
}
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",
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
"src/libplatform/tracing/recorder-default.cc",
"src/libplatform/tracing/recorder.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",
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
"src/libplatform/tracing/recorder-default.cc",
"src/libplatform/tracing/recorder.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",
]
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
} else if (is_win) {
sources -= [ "src/libplatform/tracing/recorder-default.cc" ]
sources += [ "src/libplatform/tracing/recorder-win.cc" ]
}
}
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_cppgc_shared") {
sources = [
"src/heap/base/stack.cc",
"src/heap/base/stack.h",
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",
"src/heap/base/worklist.h",
"src/heap/cppgc/sanitizers.h",
]
if (is_clang || !is_win) {
if (current_cpu == "x64") {
sources += [ "src/heap/base/asm/x64/push_registers_asm.cc" ]
} else if (current_cpu == "x86") {
sources += [ "src/heap/base/asm/ia32/push_registers_asm.cc" ]
} else if (current_cpu == "arm") {
sources += [ "src/heap/base/asm/arm/push_registers_asm.cc" ]
} else if (current_cpu == "arm64") {
sources += [ "src/heap/base/asm/arm64/push_registers_asm.cc" ]
} else if (current_cpu == "ppc64") {
sources += [ "src/heap/base/asm/ppc/push_registers_asm.cc" ]
} else if (current_cpu == "s390x") {
sources += [ "src/heap/base/asm/s390/push_registers_asm.cc" ]
} else if (current_cpu == "mipsel") {
sources += [ "src/heap/base/asm/mips/push_registers_asm.cc" ]
} else if (current_cpu == "mips64el") {
sources += [ "src/heap/base/asm/mips64/push_registers_asm.cc" ]
} else if (current_cpu == "riscv64") {
sources += [ "src/heap/base/asm/riscv64/push_registers_asm.cc" ]
}
} else if (is_win) {
if (current_cpu == "x64") {
sources += [ "src/heap/base/asm/x64/push_registers_masm.S" ]
} else if (current_cpu == "x86") {
sources += [ "src/heap/base/asm/ia32/push_registers_masm.S" ]
} else if (current_cpu == "arm64") {
sources += [ "src/heap/base/asm/arm64/push_registers_masm.S" ]
}
}
configs = [ ":internal_config" ]
public_deps = [ ":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/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-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/compiler-specific.h",
"include/cppgc/internal/finalizer-trait.h",
"include/cppgc/internal/gc-info.h",
"include/cppgc/internal/name-trait.h",
"include/cppgc/internal/persistent-node.h",
"include/cppgc/internal/pointer-policies.h",
"include/cppgc/internal/prefinalizer-handler.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",
"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" ]
}
deps = [ ":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/default-platform.cc",
"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/heap-base.cc",
"src/heap/cppgc/heap-base.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/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/page-memory.cc",
"src/heap/cppgc/page-memory.h",
"src/heap/cppgc/persistent-node.cc",
"src/heap/cppgc/platform.cc",
"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/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/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/write-barrier.cc",
"src/heap/cppgc/write-barrier.h",
]
if (cppgc_is_standalone) {
sources += [ "//base/trace_event/common/trace_event_common.h" ]
} else {
deps = [ ":v8_tracing" ]
}
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_cppgc_shared",
":v8_libbase",
":v8_libplatform",
]
}
v8_source_set("cppgc_base_for_testing") {
visibility = [ ":*" ]
sources = [
"include/cppgc/testing.h",
"src/heap/cppgc/testing.cc",
]
configs = [
":internal_config",
":cppgc_base_config",
]
public_deps = [ ":cppgc_base" ]
}
###############################################################################
# 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",
]
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",
"//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" ]
}
}
group("v8_python_base") {
data = [ ".vpython" ]
}
group("v8_clusterfuzz") {
testonly = true
deps = [
":d8",
":v8_simple_inspector_fuzzer",
]
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/toolchain:clang_x64_pointer_compression)",
]
}
}
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/rules.gni")
cr_fuchsia_package("d8_fuchsia_pkg") {
testonly = true
binary = ":d8"
manifest = "//build/config/fuchsia/tests-with-exec.cmx"
package_name_override = "d8"
}
fuchsia_package_runner("d8_fuchsia") {
testonly = true
package = ":d8_fuchsia_pkg"
package_name_override = "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",
]
}
}
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 = [
":cppgc_base_for_testing",
":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",
":cppgc_base_for_testing",
]
configs = []
public_configs = [ ":external_config" ]
}
}
v8_component("v8_cppgc_shared_for_testing") {
testonly = true
public_deps = [ ":v8_cppgc_shared" ]
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 = [
":cppgc_base_for_testing",
":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",
":cppgc_base_for_testing",
]
public_configs = [ ":external_config" ]
}
}
group("v8_cppgc_shared_for_testing") {
testonly = true
public_deps = [ ":v8_cppgc_shared" ]
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",
"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: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",
]
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_sample") {
sources = [ "samples/cppgc/cppgc-sample.cc" ]
if (v8_current_cpu == "riscv64") {
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",
]
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",
]
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") {
}
[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:export_json",
"//third_party/perfetto/src/trace_processor:storage_minimal",
"//third_party/perfetto/src/tracing:client_api",
"//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",
]
}
} # if (!build_with_chromium && v8_use_perfetto)