mirrors/node
0
0 Fork 0
mirror of https://github.com/nodejs/node.git synced 2026-10-28 10:15:07 +08:00
Code Activity

deps: update V8 to 15.2.124.38

Browse Source 
Signed-off-by: Joyee Cheung <joyeec9h3@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/65161
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
Reviewed-By: Richard Lau <richard.lau@ibm.com>
This commit is contained in:
Joyee Cheung authored and Antoine du Hamel committed 2026-10-04 22:37:35 +02:00
1 parent 773bdd175d
commit 07fa7280c1
7949 files changed
+629523 -415393
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

deps/v8/.git-blame-ignore-revs
Vendored
+6
View File
@@ -124,3 +124,9 @@ cb67be1a3842fcf6a0da18aee444e3b7ea789e04
d1b27019d3bf86360ea838c317f8505fac6d3a7e
44fe02ced6e4c6b49d627807e3b3fd0edbbeb36e
ec06bb6ce5641cf65e400ec55b7421f87d04b999
# Simplify variants flags
0476eb39b3c58671720d3ef78730821a5b7d93fa
# clang-tidy readability-braces-around-statements
32d567d072a1a62e894619d8e13485aed3889382
deps/v8/.gitignore
+31 -5
View File
@@ -23,21 +23,26 @@
*~
.#*
.*.sw?
.agents
.cache
.ccls-cache
.clangd
.clang-format-cache
.clangd
.cpplint-cache
.cproject
.DS_Store
.gclient_entries
.gdb_history
.gemini
.idea
.jetskicli
.jslint-cache
.landmines
.project
.pydevproject
.settings
.setup_worktree.lock
.torquelint-cache
.vscode
@@ -50,6 +55,8 @@
/.gcs_entries
/_*
/agents/internal
/agents/shared
/base
/build
/buildtools
@@ -62,6 +69,7 @@
/src/inspector/build/closure-compiler
/src/inspector/build/closure-compiler.tar.gz
/test/benchmarks/data
/test/benchmarks/JetStream3
/test/fuzzer/wasm_corpus/
/test/fuzzer/wasm_corpus.tar.gz
!/test/mjsunit/tools/*.log
@@ -76,11 +84,13 @@
!/third_party/antlr4
!/third_party/colorama
/third_party/colorama/src
!/third_party/cpu_features
/third_party/cpu_features/src
!/third_party/disarm
/third_party/disarm/src
!/third_party/dragonbox
/third_party/dragonbox/src/*
!/third_party/dragonbox/src/include
!/third_party/fadec
/third_party/fadec/src
!/third_party/fast_float
/third_party/fast_float/src/*
!/third_party/fast_float/src/include
@@ -101,7 +111,13 @@
!/third_party/jsoncpp
/third_party/jsoncpp/source
!/third_party/llvm-libc
/third_party/llvm-libc/src
/third_party/llvm-libc/src/*
!/third_party/llvm-libc/src/hdr
!/third_party/llvm-libc/src/include
!/third_party/llvm-libc/src/shared
!/third_party/llvm-libc/src/src
/third_party/llvm-libc/src/src/*
!/third_party/llvm-libc/src/src/__support
!/third_party/rapidhash-v8
!/third_party/re2
/third_party/re2/src
@@ -143,19 +159,29 @@ compile_commands.json
gccauses
gcsuspects
gtags.files
jit-*.dump
node_modules
tags
# Tracing and profiling output
turbo*.cfg
turbo*.dot
turbo*.json
maglev*.json
v8_trace*.json
jit-*.dump
profile-wasm*
*.heapsnapshot
v8.ignition_dispatches_table.json
bazel-bin
bazel-out
bazel-testlogs
bazel-v8
launch.json
MODULE.bazel.lock
GEMINI.md
AGENTS.md
/worktrees
!/third_party/jinja2
!/third_party/markupsafe
!/third_party/zlib
deps/v8/.gn
Vendored
+5 -3
View File
@@ -43,6 +43,8 @@ default_args = {
# These are the list of GN files that run exec_script. This whitelist exists
# to force additional review for new uses of exec_script, which is strongly
# discouraged except for gypi_to_gn calls.
exec_script_allowlist = build_dotfile_settings.exec_script_allowlist +
[ "//build_overrides/build.gni" ]
# discouraged.
exec_script_allowlist = build_dotfile_settings.exec_script_allowlist + [
"//build_overrides/build.gni",
"//gni/cluster_build.gni",
]
deps/v8/.vpython3
Vendored
+6 -6
View File
@@ -28,14 +28,14 @@ python_version: "3.11"
# Setting `verify_pep425_tag` to the list of platforms we explicitly must support
# allows us to ensure that vpython specs stay mac-arm64-friendly
verify_pep425_tag: [
{python: "cp38", abi: "cp38", platform: "manylinux1_x86_64"},
{python: "cp38", abi: "cp38", platform: "linux_arm64"},
{python: "cp311", abi: "cp311", platform: "manylinux1_x86_64"},
{python: "cp311", abi: "cp311", platform: "linux_arm64"},
{python: "cp38", abi: "cp38", platform: "macosx_10_10_intel"},
{python: "cp38", abi: "cp38", platform: "macosx_11_0_arm64"},
{python: "cp311", abi: "cp311", platform: "macosx_10_10_intel"},
{python: "cp311", abi: "cp311", platform: "macosx_11_0_arm64"},
{python: "cp38", abi: "cp38", platform: "win32"},
{python: "cp38", abi: "cp38", platform: "win_amd64"}
{python: "cp311", abi: "cp311", platform: "win32"},
{python: "cp311", abi: "cp311", platform: "win_amd64"}
]
# TODO(https://crbug.com/898348): Add in necessary wheels as Python3 versions
deps/v8/.ycm_extra_conf.py
Vendored
+2 -4
View File
@@ -63,14 +63,12 @@ def FindV8SrcFromFilename(filename):
(String) Path of 'v8/', or None if unable to find.
"""
curdir = os.path.normpath(os.path.dirname(filename))
while not (PathExists(curdir, 'v8') and PathExists(curdir, 'v8', 'DEPS')
and (PathExists(curdir, '.gclient')
or PathExists(curdir, 'v8', '.git'))):
while not PathExists(curdir, '.git'):
nextdir = os.path.normpath(os.path.join(curdir, '..'))
if nextdir == curdir:
return None
curdir = nextdir
return os.path.join(curdir, 'v8')
return curdir
def GetClangCommandFromNinjaForFilename(v8_root, filename):
deps/v8/AUTHORS
Vendored
+14 -4
View File
@@ -44,6 +44,7 @@ Julia Computing, Inc. <*@juliacomputing.com>
CodeWeavers, Inc. <*@codeweavers.com>
Alibaba, Inc. <*@alibaba-inc.com>
SiFive, Inc. <*@sifive.com>
Island Technology, Inc. <*@island.io>
Aapo Alasuutari <aapo.alasuutari@gmail.com>
Aaron Bieber <deftly@gmail.com>
@@ -78,6 +79,7 @@ Arthur Islamov <arthur@islamov.ai>
Asuka Shikina <shikina.asuka@gmail.com>
Aurèle Barrière <aurele.barriere@gmail.com>
Aviv Keller <me@aviv.sh>
Ayako Hayasaka <a.iwasaki0128@gmail.com>
Bala Avulapati <bavulapati@gmail.com>
Bangfu Tao <bangfu.tao@samsung.com>
Ben Coe <bencoe@gmail.com>
@@ -85,6 +87,9 @@ Ben Newman <ben@meteor.com>
Ben Noordhuis <info@bnoordhuis.nl>
Benjamin Tan <demoneaux@gmail.com>
Bert Belder <bertbelder@gmail.com>
Bez Sahara <ratislav.bichul2@gmail.com>
Bez Sahara <dev@astramanga.org>
Bowon Kang <rw70578@gmail.com>
Brendon Tiszka <btiszka@gmail.com>
Brice Dobry <brice.dobry@futurewei.com>
Bruno Pitrus <brunopitrus@hotmail.com>
@@ -124,7 +129,6 @@ Douglas Crosher <dtc-v8@scieneer.com>
Dusan Milosavljevic <dusan.m.milosavljevic@gmail.com>
Eden Wang <nedenwang@tencent.com>
Edoardo Marangoni <edoardo@wasmer.io>
Eliau Elkouby <eliau.elkouby@gmail.com>
Elisha Hollander <just4now666666@gmail.com>
Eric Rannaud <eric.rannaud@gmail.com>
Erich Ocean <erich.ocean@me.com>
@@ -133,7 +137,7 @@ Fedor Indutny <fedor@indutny.com>
Felix Geisendörfer <haimuiba@gmail.com>
Feng Yu <f3n67u@gmail.com>
Filipe David Manana <fdmanana@gmail.com>
Florian Loitsch <floitsch@rivosinc.com>
Florian Loitsch <floitsch@meta.com>
Frank Lemanschik <frank@dspeed.eu>
Franziska Hinkelmann <franziska.hinkelmann@gmail.com>
Gao Sheng <gaosheng08@meituan.com>
@@ -142,6 +146,7 @@ Gergely Nagy <ngg@ngg.hu>
Gilang Mentari Hamidy <gilang@hamidy.net>
Giovanny Gutierrez <giovannygutierrez@gmail.com>
Gus Caplan <me@gus.host>
Guy Bedford <guybedford@gmail.com>
Gwang Yoon Hwang <ryumiel@company100.net>
Haichuan Wang <hc.opensource@gmail.com>
Hannu Trey <hannu.trey@gmail.com>
@@ -165,9 +170,11 @@ Jaime Bernardo <jaime@janeasystems.com>
Jake Hughes <jh@jakehughes.uk>
James M Snell <jasnell@gmail.com>
James Pike <g00gle@chilon.net>
Jamie Magee <jamie.magee@gmail.com>
Jan Krems <jan.krems@gmail.com>
Jan de Mooij <jandemooij@gmail.com>
Janusz Majnert <jmajnert@gmail.com>
Jarden Xian <zeroxiaobai@gmail.com>
Javad Amiri <javad.amiri@anu.edu.au>
Jay Freeman <saurik@saurik.com>
Jeroen Bobbeldijk <jerbob92@gmail.com>
@@ -176,6 +183,7 @@ Jesper van den Ende <jespertheend@gmail.com>
Ji Qiu <qiuji@iscas.ac.cn>
Jiawen Geng <technicalcute@gmail.com>
Jiaxun Yang <jiaxun.yang@flygoat.com>
Jihyeon Jeong <smartphonewithbear@gmail.com>
Joel Stanley <joel@jms.id.au>
Johan Bergström <johan@bergstroem.nu>
Johan Levin <johan13@gmail.com>
@@ -189,7 +197,7 @@ Junha Park <jpark3@scu.edu>
Junming Huang <kiminghjm@gmail.com>
Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Karl Skomski <karl@skomski.com>
Kasper Lund <kasperl@rivosinc.com>
Kasper Lund <kasperl@meta.com>
Keith Smiley <keithbsmiley@gmail.com>
Kenta Moriuchi <moriken@kimamass.com>
Kevin Gibbons <bakkot@gmail.com>
@@ -240,6 +248,7 @@ Nicolas Antonius Ernst Leopold Maria Kaiser <nikai@nikai.net>
Nicolò Ribaudo <nicolo.ribaudo@gmail.com>
Niek van der Maas <mail@niekvandermaas.nl>
Niklas Hambüchen <mail@nh2.me>
Niklas Wenzel <dev@nikwen.de>
Noj Vek <nojvek@gmail.com>
Oleksandr Chekhovskyi <oleksandr.chekhovskyi@gmail.com>
Oliver Dunk <oliver@oliverdunk.com>
@@ -287,11 +296,11 @@ Sergey Markelov <sergionso@gmail.com>
Shawn Anastasio <shawnanastasio@gmail.com>
Shawn Presser <shawnpresser@gmail.com>
Sho Miyamoto <me@shqld.dev>
Shumaf Lovpache <soarex16@gmail.com>
Stefan Penner <stefan.penner@gmail.com>
Stefan Stojanovic <stefko.stojanovic@gmail.com>
Stephan Hartmann <stha09@googlemail.com>
Stephen Belanger <stephen.belanger@datadoghq.com>
Steven R. Loomis <srl295@gmail.com>
Sylvestre Ledru <sledru@mozilla.com>
Takeshi Yoneda <takeshi@tetrate.io>
Taketoshi Aono <brn@b6n.ch>
@@ -361,3 +370,4 @@ Liam Wachter <liam.g.wachter@gmail.com>
Flavio Toffalini <flavio87@gmail.com>
Mathias Payer <mathias.payer@gmail.com>
Christian Wressnegger <intellisec.de@gmail.com>
Zekai Zheng <zzheng@atlassian.com>
deps/v8/BUILD.bazel
Vendored
+287 -160
View File
@@ -73,6 +73,7 @@ load(":bazel/v8-non-pointer-compression.bzl", "v8_binary_non_pointer_compression
# cppgc_enable_check_assignments_in_prefinalizers
# cppgc_enable_slim_write_barrier
# cppgc_enable_object_names
# cppgc_enable_object_section_gcinfo
# cppgc_enable_pointer_compression
# cppgc_enable_slow_api_checks
# cppgc_enable_verify_heap
@@ -93,6 +94,11 @@ v8_flag(name = "v8_annotate_torque_ir")
v8_flag(name = "v8_code_comments")
v8_flag(
name = "v8_cppgc_microtask_queue",
default = False,
)
v8_flag(
name = "v8_deprecation_warnings",
default = True,
@@ -170,6 +176,11 @@ v8_flag(
v8_flag(name = "v8_enable_experimental_tq_to_tsa")
v8_flag(
name = "v8_use_host_cpu_arm_features",
default = True,
)
# Default setting for v8_enable_maglev
selects.config_setting_group(
name = "maglev_by_default",
@@ -495,6 +506,7 @@ v8_config(
conditional_defines = {
"v8_android_log_stdout": "V8_ANDROID_LOG_STDOUT",
"v8_code_comments": "V8_CODE_COMMENTS",
"v8_cppgc_microtask_queue": "V8_CPPGC_MICROTASK_QUEUE",
"v8_deprecation_warnings": "V8_DEPRECATION_WARNINGS",
"v8_imminent_deprecation_warnings": "V8_IMMINENT_DEPRECATION_WARNINGS",
"v8_enable_debug_code": "V8_ENABLE_DEBUG_CODE",
@@ -521,6 +533,7 @@ v8_config(
"v8_jitless": "V8_JITLESS",
"v8_enable_vtunejit": "ENABLE_VTUNE_JIT_INTERFACE",
"v8_enable_undefined_double": "V8_ENABLE_UNDEFINED_DOUBLE",
"v8_use_host_cpu_arm_features": "V8_USE_HOST_CPU_ARM_FEATURES",
},
defines = [
"GOOGLE3",
@@ -551,13 +564,19 @@ v8_config(
}) + select(
{
"@v8//bazel/config:v8_target_ia32": ["V8_TARGET_ARCH_IA32"],
"@v8//bazel/config:v8_target_x64": ["V8_TARGET_ARCH_X64"],
"@v8//bazel/config:v8_target_x64": [
"V8_TARGET_ARCH_X64",
"V8_ENABLE_SPARKPLUG_PLUS",
],
"@v8//bazel/config:v8_target_arm": [
"V8_TARGET_ARCH_ARM",
"CAN_USE_ARMV7_INSTRUCTIONS",
"CAN_USE_VFP3_INSTRUCTIONS",
],
"@v8//bazel/config:v8_target_arm64": ["V8_TARGET_ARCH_ARM64"],
"@v8//bazel/config:v8_target_arm64": [
"V8_TARGET_ARCH_ARM64",
"V8_ENABLE_SPARKPLUG_PLUS",
],
"@v8//bazel/config:v8_target_s390x": [
"V8_TARGET_ARCH_S390X"
],
@@ -597,12 +616,13 @@ v8_config(
":is_v8_enable_pointer_compression": [
"V8_COMPRESS_POINTERS",
"V8_31BIT_SMIS_ON_64BIT_ARCH",
"V8_CONTIGUOUS_COMPRESSED_RO_SPACE",
"V8_CONTIGUOUS_COMPRESSED_RO_SPACE_SIZE_MB=8",
],
"//conditions:default": [],
}) + select({
":enable_pointer_compression_shared_cage": [
"V8_COMPRESS_POINTERS_IN_SHARED_CAGE",
"V8_CONTIGUOUS_COMPRESSED_RO_SPACE_SIZE_MB=8",
],
":enable_pointer_compression_multiple_cages": [
"V8_COMPRESS_POINTERS_IN_MULTIPLE_CAGES",
@@ -837,8 +857,9 @@ filegroup(
"src/base/compiler-specific.h",
"src/base/container-utils.h",
"src/base/contextual.h",
"src/base/cpu.cc",
"src/base/cpu.h",
"src/base/cpu/cpu.cc",
"src/base/cpu/cpu.h",
"src/base/cpu/cpu-helper.h",
"src/base/debug/stack_trace.cc",
"src/base/debug/stack_trace.h",
"src/base/discriminated-union.h",
@@ -960,6 +981,8 @@ filegroup(
"src/base/vlq.h",
"src/base/vlq-base64.cc",
"src/base/vlq-base64.h",
"third_party/rapidhash-v8/rapidhash.h",
"third_party/rapidhash-v8/secret.h",
":v8_config_headers_files",
":v8_flags",
":v8_headers_files",
@@ -991,6 +1014,25 @@ filegroup(
"src/base/platform/platform-win32.h",
"src/base/win32-headers.h",
],
}) + select({
"@v8//bazel/config:v8_target_x64": [
"src/base/cpu/cpu-x86.cc",
],
"@v8//bazel/config:v8_target_ia32": [
"src/base/cpu/cpu-x86.cc",
],
"@v8//bazel/config:v8_target_arm64": [
"src/base/cpu/cpu-arm.cc",
],
"@v8//bazel/config:v8_target_arm": [
"src/base/cpu/cpu-arm.cc",
],
"@v8//bazel/config:v8_target_ppc64le": [
"src/base/cpu/cpu-ppc.cc",
],
"@v8//bazel/config:v8_target_riscv64": [
"src/base/cpu/cpu-riscv.cc",
],
}),
visibility = ["//visibility:public"],
)
@@ -1092,6 +1134,7 @@ filegroup(
"src/builtins/frame-arguments.tq",
"src/builtins/frames.tq",
"src/builtins/function.tq",
"src/builtins/generator.tq",
"src/builtins/growable-fixed-array.tq",
"src/builtins/ic.tq",
"src/builtins/ic-callable.tq",
@@ -1211,7 +1254,9 @@ filegroup(
"src/objects/embedder-data-array.tq",
"src/objects/feedback-cell.tq",
"src/objects/feedback-vector.tq",
"src/objects/fixed-array-base.tq",
"src/objects/fixed-array.tq",
"src/objects/fixed-primitive-array.tq",
"src/objects/foreign.tq",
"src/objects/free-space.tq",
"src/objects/heap-number.tq",
@@ -1224,6 +1269,7 @@ filegroup(
"src/objects/js-disposable-stack.tq",
"src/objects/js-function.tq",
"src/objects/js-generator.tq",
"src/objects/js-interceptor-map.tq",
"src/objects/js-iterator-helpers.tq",
"src/objects/js-objects.tq",
"src/objects/js-promise.tq",
@@ -1272,7 +1318,6 @@ filegroup(
"third_party/v8/builtins/array-sort.tq",
] + select({
":is_v8_enable_webassembly": [
"src/builtins/js-to-js.tq",
"src/builtins/js-to-wasm.tq",
"src/builtins/wasm.tq",
"src/builtins/wasm-strings.tq",
@@ -1280,6 +1325,9 @@ filegroup(
"src/debug/debug-wasm-objects.tq",
"src/wasm/wasm-objects.tq",
],
":is_v8_enable_drumbrake": [
"src/wasm/wasm-interpreter-objects.tq"
],
"//conditions:default": [],
}),
)
@@ -1386,7 +1434,6 @@ filegroup(
"src/api/api-inl.h",
"src/api/api-natives.cc",
"src/api/api-natives.h",
"src/asmjs/asm-js.h",
"src/ast/ast.cc",
"src/ast/ast.h",
"src/ast/ast-function-literal-id-reindexer.cc",
@@ -1479,6 +1526,7 @@ filegroup(
"src/builtins/constants-table-builder.h",
"src/builtins/data-view-ops.h",
"src/builtins/profile-data-reader.h",
"src/builtins/superspread.h",
"src/codegen/aligned-slot-allocator.cc",
"src/codegen/aligned-slot-allocator.h",
"src/codegen/assembler.cc",
@@ -1578,6 +1626,8 @@ filegroup(
"src/common/segmented-table.h",
"src/common/segmented-table-inl.h",
"src/common/simd128.h",
"src/common/synchronization-point-support.cc",
"src/common/synchronization-point-support.h",
"src/compiler-dispatcher/lazy-compile-dispatcher.cc",
"src/compiler-dispatcher/lazy-compile-dispatcher.h",
"src/compiler-dispatcher/optimizing-compile-dispatcher.cc",
@@ -1703,8 +1753,6 @@ filegroup(
"src/extensions/externalize-string-extension.h",
"src/extensions/gc-extension.cc",
"src/extensions/gc-extension.h",
"src/extensions/ignition-statistics-extension.cc",
"src/extensions/ignition-statistics-extension.h",
"src/extensions/statistics-extension.cc",
"src/extensions/statistics-extension.h",
"src/extensions/trigger-failure-extension.cc",
@@ -1718,6 +1766,9 @@ filegroup(
"src/handles/global-handles.cc",
"src/handles/global-handles.h",
"src/handles/global-handles-inl.h",
"src/handles/handle-scope-implementer.cc",
"src/handles/handle-scope-implementer.h",
"src/handles/handle-scope-implementer-inl.h",
"src/handles/handles.cc",
"src/handles/handles.h",
"src/handles/handles-inl.h",
@@ -1762,7 +1813,6 @@ filegroup(
"src/heap/cppgc-js/cpp-heap.cc",
"src/heap/cppgc-js/cpp-heap.h",
"src/heap/cppgc-js/cpp-marking-state.h",
"src/heap/cppgc-js/cpp-marking-state-inl.h",
"src/heap/cppgc-js/cpp-snapshot.cc",
"src/heap/cppgc-js/cpp-snapshot.h",
"src/heap/cppgc-js/cross-heap-remembered-set.cc",
@@ -1781,7 +1831,6 @@ filegroup(
"src/heap/evacuation-allocator-inl.h",
"src/heap/evacuation-verifier.cc",
"src/heap/evacuation-verifier.h",
"src/heap/evacuation-verifier-inl.h",
"src/heap/factory.cc",
"src/heap/factory.h",
"src/heap/factory-base.cc",
@@ -1904,6 +1953,8 @@ filegroup(
"src/heap/parallel-work-item.h",
"src/heap/parked-scope-inl.h",
"src/heap/parked-scope.h",
"src/heap/pending-allocations.cc",
"src/heap/pending-allocations.h",
"src/heap/pretenuring-handler.cc",
"src/heap/pretenuring-handler.h",
"src/heap/pretenuring-handler-inl.h",
@@ -2082,7 +2133,6 @@ filegroup(
"src/objects/contexts.h",
"src/objects/contexts-inl.h",
"src/objects/cpp-heap-external-object.h",
"src/objects/cpp-heap-external-object-inl.h",
"src/objects/cpp-heap-object-wrapper.h",
"src/objects/cpp-heap-object-wrapper-inl.h",
"src/objects/data-handler.h",
@@ -2112,6 +2162,7 @@ filegroup(
"src/objects/embedder-data-slot-inl.h",
"src/objects/feedback-cell.h",
"src/objects/feedback-cell-inl.h",
"src/objects/feedback-transition-table.cc",
"src/objects/feedback-vector.cc",
"src/objects/feedback-vector.h",
"src/objects/feedback-vector-inl.h",
@@ -2119,9 +2170,13 @@ filegroup(
"src/objects/field-index-inl.h",
"src/objects/field-type.cc",
"src/objects/field-type.h",
"src/objects/fixed-array-base.h",
"src/objects/fixed-array-base-inl.h",
"src/objects/fixed-array.cc",
"src/objects/fixed-array.h",
"src/objects/fixed-array-inl.h",
"src/objects/fixed-primitive-array.h",
"src/objects/fixed-primitive-array-inl.h",
"src/objects/foreign.h",
"src/objects/foreign-inl.h",
"src/objects/free-space.h",
@@ -2130,10 +2185,14 @@ filegroup(
"src/objects/function-syntax-kind.h",
"src/objects/hash-table.h",
"src/objects/hash-table-inl.h",
"src/objects/hash-seed-wrapper.h",
"src/objects/hash-seed-wrapper-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/heap-object-field-inl.h",
"src/objects/heap-object-set-map-inl.h",
"src/objects/instance-type.h",
"src/objects/instance-type-checker.h",
"src/objects/instance-type-inl.h",
@@ -2153,6 +2212,9 @@ filegroup(
"src/objects/js-collection-inl.h",
"src/objects/js-collection-iterator.h",
"src/objects/js-collection-iterator-inl.h",
"src/objects/js-data-object-builder.cc",
"src/objects/js-data-object-builder.h",
"src/objects/js-data-object-builder-inl.h",
"src/objects/js-disposable-stack.cc",
"src/objects/js-disposable-stack.h",
"src/objects/js-disposable-stack-inl.h",
@@ -2161,6 +2223,8 @@ filegroup(
"src/objects/js-function-inl.h",
"src/objects/js-generator.h",
"src/objects/js-generator-inl.h",
"src/objects/js-interceptor-map.h",
"src/objects/js-interceptor-map-inl.h",
"src/objects/js-iterator-helpers.h",
"src/objects/js-iterator-helpers-inl.h",
"src/objects/js-objects.cc",
@@ -2181,10 +2245,8 @@ filegroup(
"src/objects/js-shadow-realm.h",
"src/objects/js-shadow-realm-inl.h",
"src/objects/js-shared-array.h",
"src/objects/js-shared-array-inl.h",
"src/objects/js-struct.cc",
"src/objects/js-struct.h",
"src/objects/js-struct-inl.h",
# Temporal is currently gn-only
# "src/objects/js-temporal-objects.cc",
# "src/objects/js-temporal-objects.h",
@@ -2211,6 +2273,8 @@ filegroup(
"src/objects/map.cc",
"src/objects/map.h",
"src/objects/map-inl.h",
"src/objects/map-word.h",
"src/objects/map-word-inl.h",
"src/objects/map-updater.cc",
"src/objects/map-updater.h",
"src/objects/maybe-object.h",
@@ -2232,6 +2296,10 @@ filegroup(
"src/objects/object-macros-undef.h",
"src/objects/object-type.cc",
"src/objects/object-type.h",
"src/objects/object-predicates.h",
"src/objects/object-predicates-inl.h",
"src/objects/oddball-predicates.h",
"src/objects/oddball-predicates-inl.h",
"src/objects/objects.cc",
"src/objects/objects.h",
"src/objects/objects-body-descriptors.h",
@@ -2252,8 +2320,9 @@ filegroup(
"src/objects/ordered-hash-table.cc",
"src/objects/ordered-hash-table.h",
"src/objects/ordered-hash-table-inl.h",
"src/objects/pod-array.h",
"src/objects/pod-array-inl.h",
"src/objects/primitive-heap-object.h",
"src/objects/primitive-heap-object-inl.h",
"src/objects/promise.h",
"src/objects/promise-inl.h",
"src/objects/property.cc",
@@ -2267,6 +2336,7 @@ filegroup(
"src/objects/property-descriptor-object.h",
"src/objects/property-descriptor-object-inl.h",
"src/objects/property-details.h",
"src/objects/property-details-inl.h",
"src/objects/prototype.h",
"src/objects/prototype-info.h",
"src/objects/prototype-info-inl.h",
@@ -2290,6 +2360,7 @@ filegroup(
"src/objects/slots-inl.h",
"src/objects/smi.h",
"src/objects/smi-inl.h",
"src/objects/sort-state.h",
"src/objects/source-text-module.cc",
"src/objects/source-text-module.h",
"src/objects/source-text-module-inl.h",
@@ -2332,8 +2403,6 @@ filegroup(
"src/objects/templates.cc",
"src/objects/templates.h",
"src/objects/templates-inl.h",
"src/objects/torque-defined-classes.h",
"src/objects/torque-defined-classes-inl.h",
"src/objects/transitions.cc",
"src/objects/transitions.h",
"src/objects/transitions-inl.h",
@@ -2394,7 +2463,7 @@ filegroup(
"src/profiler/heap-snapshot-common.h",
"src/profiler/heap-snapshot-generator.cc",
"src/profiler/heap-snapshot-generator.h",
"src/profiler/heap-snapshot-generator-inl.h",
"src/profiler/output-stream-writer.cc",
"src/profiler/output-stream-writer.h",
"src/profiler/profile-generator.cc",
"src/profiler/profile-generator.h",
@@ -2429,8 +2498,6 @@ filegroup(
"src/regexp/regexp-ast.h",
"src/regexp/regexp-ast-printer.cc",
"src/regexp/regexp-ast-printer.h",
"src/regexp/regexp-bytecode-analysis.cc",
"src/regexp/regexp-bytecode-analysis.h",
"src/regexp/regexp-bytecode-generator.cc",
"src/regexp/regexp-bytecode-generator.h",
"src/regexp/regexp-bytecode-generator-inl.h",
@@ -2530,9 +2597,6 @@ filegroup(
"src/sandbox/cppheap-pointer-table.cc",
"src/sandbox/cppheap-pointer-table.h",
"src/sandbox/cppheap-pointer-table-inl.h",
"src/sandbox/code-pointer-table.cc",
"src/sandbox/code-pointer-table.h",
"src/sandbox/code-pointer-table-inl.h",
"src/sandbox/js-dispatch-table.cc",
"src/sandbox/js-dispatch-table.h",
"src/sandbox/js-dispatch-table-inl.h",
@@ -2541,8 +2605,6 @@ filegroup(
"src/sandbox/trusted-pointer-table.cc",
"src/sandbox/trusted-pointer-table.h",
"src/sandbox/trusted-pointer-table-inl.h",
"src/sandbox/code-pointer.h",
"src/sandbox/code-pointer-inl.h",
"src/sandbox/code-sandboxing-mode.h",
"src/sandbox/compactible-external-entity-table-inl.h",
"src/sandbox/compactible-external-entity-table.h",
@@ -2568,6 +2630,8 @@ filegroup(
"src/sandbox/tagged-payload.h",
"src/sandbox/testing.cc",
"src/sandbox/testing.h",
"src/sandbox/trap-fuzzer.cc",
"src/sandbox/trap-fuzzer.h",
"src/snapshot/builtins-effects-dummy.cc",
"src/snapshot/code-serializer.cc",
"src/snapshot/code-serializer.h",
@@ -2682,6 +2746,7 @@ filegroup(
"src/utils/utils-inl.h",
"src/utils/version.cc",
"src/utils/version.h",
"src/wasm/effect-handler.h",
"src/zone/accounting-allocator.cc",
"src/zone/accounting-allocator.h",
"src/zone/type-stats.cc",
@@ -2701,6 +2766,7 @@ filegroup(
"src/zone/zone-utils.h",
"third_party/rapidhash-v8/rapidhash.h",
"third_party/rapidhash-v8/secret.h",
"third_party/v8/builtins/array-sort.h",
"third_party/siphash/halfsiphash.cc",
"third_party/siphash/halfsiphash.h",
"third_party/utf8-decoder/utf8-decoder.h",
@@ -2871,6 +2937,7 @@ filegroup(
"src/codegen/riscv/constant-riscv-f.h",
"src/codegen/riscv/constant-riscv-m.h",
"src/codegen/riscv/constant-riscv-v.h",
"src/codegen/riscv/constant-riscv-zfa.h",
"src/codegen/riscv/constant-riscv-zicsr.h",
"src/codegen/riscv/constant-riscv-zifencei.h",
"src/codegen/riscv/constants-riscv.h",
@@ -2882,6 +2949,8 @@ filegroup(
"src/codegen/riscv/extension-riscv-inl.h",
"src/codegen/riscv/extension-riscv-m.h",
"src/codegen/riscv/extension-riscv-v.h",
"src/codegen/riscv/extension-riscv-zfa.cc",
"src/codegen/riscv/extension-riscv-zfa.h",
"src/codegen/riscv/extension-riscv-zicsr.h",
"src/codegen/riscv/extension-riscv-zifencei.h",
"src/codegen/riscv/extension-riscv-zimop.cc",
@@ -2974,13 +3043,17 @@ filegroup(
"src/maglev/maglev-graph-printer.h",
"src/maglev/maglev-graph-processor.h",
"src/maglev/maglev-graph-verifier.h",
"src/maglev/maglev-graph-serializer.h",
"src/maglev/maglev-graph.h",
"src/maglev/maglev-inlining.h",
"src/maglev/maglev-loop-peeler.h",
"src/maglev/maglev-interpreter-frame-state.h",
"src/maglev/maglev-ir-inl.h",
"src/maglev/maglev-ir.h",
"src/maglev/maglev-kna-processor.h",
"src/maglev/maglev-map-inference.h",
"src/maglev/maglev-node-type.h",
"src/maglev/maglev-phase.h",
"src/maglev/maglev-phi-representation-selector.h",
"src/maglev/maglev-truncation.h",
"src/maglev/maglev-pipeline-statistics.h",
@@ -3003,22 +3076,29 @@ filegroup(
"src/maglev/maglev-compiler.cc",
"src/maglev/maglev-concurrent-dispatcher.cc",
"src/maglev/maglev-graph-builder.cc",
"src/maglev/maglev-kna-processor.cc",
"src/maglev/maglev-known-node-aspects.cc",
"src/maglev/maglev-known-node-aspects.h",
"src/maglev/maglev-cse.h",
"src/maglev/maglev-graph-labeller.cc",
"src/maglev/maglev-graph-optimizer.cc",
"src/maglev/maglev-graph-printer.cc",
"src/maglev/maglev-graph-serializer.cc",
"src/maglev/maglev-graph.cc",
"src/maglev/maglev-inlining.cc",
"src/maglev/maglev-loop-peeler.cc",
"src/maglev/maglev-interpreter-frame-state.cc",
"src/maglev/maglev-ir.cc",
"src/maglev/maglev-node-type.cc",
"src/maglev/maglev-phi-representation-selector.cc",
"src/maglev/maglev-tracer.h",
"src/maglev/maglev-truncation.cc",
"src/maglev/maglev-pipeline-statistics.cc",
"src/maglev/maglev-range-verification.cc",
"src/maglev/maglev-regalloc.cc",
"src/maglev/maglev.cc",
"src/maglev/turbolev-escape-analysis.cc",
"src/maglev/turbolev-escape-analysis.h",
],
"//conditions:default": [],
}) + select({
@@ -3051,14 +3131,6 @@ filegroup(
"//conditions:default": [],
}) + select({
":is_v8_enable_webassembly": [
"src/asmjs/asm-js.cc",
"src/asmjs/asm-names.h",
"src/asmjs/asm-parser.cc",
"src/asmjs/asm-parser.h",
"src/asmjs/asm-scanner.cc",
"src/asmjs/asm-scanner.h",
"src/asmjs/asm-types.cc",
"src/asmjs/asm-types.h",
"src/compiler/turboshaft/wasm-dead-code-elimination-phase.cc",
"src/compiler/turboshaft/wasm-dead-code-elimination-phase.h",
"src/debug/debug-wasm-objects.cc",
@@ -3076,6 +3148,7 @@ filegroup(
"src/wasm/baseline/liftoff-assembler.h",
"src/wasm/baseline/liftoff-assembler-defs.h",
"src/wasm/baseline/liftoff-assembler-inl.h",
"src/wasm/baseline/liftoff-bailout-reasons.h",
"src/wasm/baseline/liftoff-compiler.cc",
"src/wasm/baseline/liftoff-compiler.h",
"src/wasm/baseline/liftoff-register.h",
@@ -3120,12 +3193,9 @@ filegroup(
"src/wasm/module-instantiate.h",
"src/wasm/names-provider.cc",
"src/wasm/names-provider.h",
"src/wasm/object-access.h",
"src/wasm/pgo.cc",
"src/wasm/pgo.h",
"src/wasm/signature-hashing.h",
"src/wasm/simd-shuffle.cc",
"src/wasm/simd-shuffle.h",
"src/wasm/stacks.cc",
"src/wasm/stacks.h",
"src/wasm/std-object-sizes.h",
@@ -3134,7 +3204,6 @@ filegroup(
"src/wasm/string-builder.h",
"src/wasm/string-builder-multiline.h",
"src/wasm/struct-types.h",
"src/wasm/sync-streaming-decoder.cc",
"src/wasm/turboshaft-graph-interface.cc",
"src/wasm/turboshaft-graph-interface.h",
"src/wasm/turboshaft-graph-interface-inl.h",
@@ -3156,6 +3225,7 @@ filegroup(
"src/wasm/wasm-disassembler.h",
"src/wasm/wasm-disassembler-impl.h",
"src/wasm/wasm-engine.cc",
"src/wasm/wasm-engine-globals.h",
"src/wasm/wasm-engine.h",
"src/wasm/wasm-export-wrapper-cache.cc",
"src/wasm/wasm-export-wrapper-cache.h",
@@ -3173,6 +3243,8 @@ filegroup(
"src/wasm/wasm-js.cc",
"src/wasm/wasm-js.h",
"src/wasm/wasm-linkage.h",
"src/wasm/wasm-memory-map-descriptor.cc",
"src/wasm/wasm-memory-map-descriptor.h",
"src/wasm/wasm-module.cc",
"src/wasm/wasm-module.h",
"src/wasm/wasm-module-builder.cc",
@@ -3197,9 +3269,7 @@ filegroup(
"src/wasm/wasm-value.h",
"src/wasm/well-known-imports.cc",
"src/wasm/well-known-imports.h",
"src/wasm/wrappers.cc",
"src/wasm/wrappers.h",
"src/wasm/wrappers-inl.h",
"src/wasm/wasm-wrapper-cache-inl.h",
"third_party/utf8-decoder/generalized-utf8-decoder.h",
],
@@ -3211,7 +3281,6 @@ filegroup(
"src/wasm/interpreter/wasm-interpreter.h",
"src/wasm/interpreter/wasm-interpreter-inl.h",
"src/wasm/interpreter/wasm-interpreter-objects.cc",
"src/wasm/interpreter/wasm-interpreter-objects-inl.h",
"src/wasm/interpreter/wasm-interpreter-objects.h",
"src/wasm/interpreter/wasm-interpreter-runtime.cc",
"src/wasm/interpreter/wasm-interpreter-runtime-inl.h",
@@ -3307,6 +3376,8 @@ filegroup(
"src/compiler/backend/instruction-scheduler.h",
"src/compiler/backend/instruction-selector.cc",
"src/compiler/backend/instruction-selector.h",
"src/compiler/backend/simd-shuffle.cc",
"src/compiler/backend/simd-shuffle.h",
"src/compiler/backend/instruction-selector-impl.h",
"src/compiler/backend/jump-threading.cc",
"src/compiler/backend/jump-threading.h",
@@ -3460,8 +3531,6 @@ filegroup(
"src/compiler/operator-properties.h",
"src/compiler/osr.cc",
"src/compiler/osr.h",
"src/compiler/pair-load-store-reducer.cc",
"src/compiler/pair-load-store-reducer.h",
"src/compiler/per-isolate-compiler-cache.h",
"src/compiler/persistent-map.h",
"src/compiler/phase.h",
@@ -3497,8 +3566,6 @@ filegroup(
"src/compiler/simplified-operator-reducer.h",
"src/compiler/state-values-utils.cc",
"src/compiler/state-values-utils.h",
"src/compiler/string-builder-optimizer.cc",
"src/compiler/string-builder-optimizer.h",
"src/compiler/turbofan.h",
"src/compiler/turbofan-enabled.cc",
"src/compiler/turbofan-graph.cc",
@@ -3578,6 +3645,9 @@ filegroup(
"src/compiler/turboshaft/load-store-verification-reducer.h",
"src/compiler/turboshaft/loop-finder.cc",
"src/compiler/turboshaft/loop-finder.h",
"src/compiler/turboshaft/loop-optimization-phase.cc",
"src/compiler/turboshaft/loop-optimization-phase.h",
"src/compiler/turboshaft/loop-optimization-reducer.h",
"src/compiler/turboshaft/loop-peeling-phase.cc",
"src/compiler/turboshaft/loop-peeling-phase.h",
"src/compiler/turboshaft/loop-peeling-reducer.h",
@@ -3589,6 +3659,8 @@ filegroup(
"src/compiler/turboshaft/machine-lowering-phase.h",
"src/compiler/turboshaft/machine-lowering-reducer-inl.h",
"src/compiler/turboshaft/maglev-assert-types-reducer.h",
"src/compiler/turboshaft/random-rescheduling-phase.cc",
"src/compiler/turboshaft/random-rescheduling-phase.h",
"src/compiler/turboshaft/turbolev-early-lowering-reducer-inl.h",
"src/compiler/turboshaft/turbolev-frontend-pipeline.cc",
"src/compiler/turboshaft/turbolev-frontend-pipeline.h",
@@ -3601,8 +3673,8 @@ filegroup(
"src/compiler/turboshaft/operations.cc",
"src/compiler/turboshaft/operations.h",
"src/compiler/turboshaft/opmasks.h",
"src/compiler/turboshaft/optimize-phase.cc",
"src/compiler/turboshaft/optimize-phase.h",
"src/compiler/turboshaft/memory-optimization-phase.cc",
"src/compiler/turboshaft/memory-optimization-phase.h",
"src/compiler/turboshaft/phase.cc",
"src/compiler/turboshaft/phase.h",
"src/compiler/turboshaft/pipelines.cc",
@@ -3624,8 +3696,8 @@ filegroup(
"src/compiler/turboshaft/snapshot-table.h",
"src/compiler/turboshaft/snapshot-table-opindex.h",
"src/compiler/turboshaft/stack-check-lowering-reducer.h",
"src/compiler/turboshaft/store-store-elimination-phase.cc",
"src/compiler/turboshaft/store-store-elimination-phase.h",
"src/compiler/turboshaft/load-elimination-phase.cc",
"src/compiler/turboshaft/load-elimination-phase.h",
"src/compiler/turboshaft/store-store-elimination-reducer-inl.h",
"src/compiler/turboshaft/string-escape-analysis-reducer.cc",
"src/compiler/turboshaft/string-escape-analysis-reducer.h",
@@ -3738,6 +3810,7 @@ filegroup(
"src/compiler/turboshaft/wasm-gc-optimize-phase.h",
"src/compiler/turboshaft/wasm-gc-typed-optimization-reducer.cc",
"src/compiler/turboshaft/wasm-gc-typed-optimization-reducer.h",
"src/compiler/turboshaft/wasm-load-elimination-reducer.cc",
"src/compiler/turboshaft/wasm-load-elimination-reducer.h",
"src/compiler/turboshaft/wasm-in-js-inlining-phase.cc",
"src/compiler/turboshaft/wasm-in-js-inlining-phase.h",
@@ -3749,6 +3822,9 @@ filegroup(
"src/compiler/turboshaft/wasm-optimize-phase.h",
"src/compiler/turboshaft/wasm-turboshaft-compiler.cc",
"src/compiler/turboshaft/wasm-turboshaft-compiler.h",
"src/compiler/turboshaft/wasm-wrappers-inl.h",
"src/compiler/turboshaft/wasm-wrappers.cc",
"src/compiler/turboshaft/wasm-wrappers.h",
"src/compiler/turboshaft/wasm-shuffle-reducer.cc",
"src/compiler/turboshaft/wasm-shuffle-reducer.h",
"src/compiler/turboshaft/wasm-simd-phase.cc",
@@ -3793,6 +3869,7 @@ filegroup(
"src/maglev/maglev-compilation-unit.h",
"src/maglev/maglev-known-node-aspects.cc",
"src/maglev/maglev-known-node-aspects.h",
"src/maglev/maglev-cse.h",
"src/maglev/maglev-graph-builder.cc",
"src/maglev/maglev-graph-builder.h",
"src/maglev/maglev-graph-optimizer.cc",
@@ -3803,16 +3880,21 @@ filegroup(
"src/maglev/maglev-graph-labeller.cc",
"src/maglev/maglev-graph-printer.cc",
"src/maglev/maglev-graph-printer.h",
"src/maglev/maglev-graph-serializer.cc",
"src/maglev/maglev-graph-serializer.h",
"src/maglev/maglev-graph-processor.h",
"src/maglev/maglev-graph-verifier.h",
"src/maglev/maglev-inlining.cc",
"src/maglev/maglev-inlining.h",
"src/maglev/maglev-interpreter-frame-state.cc",
"src/maglev/maglev-interpreter-frame-state.h",
"src/maglev/maglev-loop-peeler.cc",
"src/maglev/maglev-loop-peeler.h",
"src/maglev/maglev-ir.cc",
"src/maglev/maglev-ir.h",
"src/maglev/maglev-ir-inl.h",
"src/maglev/maglev-kna-processor.h",
"src/maglev/maglev-kna-processor.cc",
"src/maglev/maglev-node-type.cc",
"src/maglev/maglev-node-type.h",
"src/maglev/maglev-range.h",
@@ -3822,12 +3904,16 @@ filegroup(
"src/maglev/maglev-reducer-inl.h",
"src/maglev/maglev-reducer.h",
"src/maglev/maglev-register-frame-array.h",
"src/maglev/maglev-phase.h",
"src/maglev/maglev-phi-representation-selector.cc",
"src/maglev/maglev-phi-representation-selector.h",
"src/maglev/maglev-tracer.h",
"src/maglev/maglev-truncation.cc",
"src/maglev/maglev-truncation.h",
"src/maglev/maglev-post-hoc-optimizations-processors.h",
"src/maglev/maglev-pre-regalloc-codegen-processors.h",
"src/maglev/turbolev-escape-analysis.cc",
"src/maglev/turbolev-escape-analysis.h",
],
}),
)
@@ -3955,97 +4041,97 @@ filegroup(
filegroup(
name = "cppgc_base_files",
srcs = [
"src/heap/cppgc/allocation.cc",
"src/heap/cppgc/caged-heap.h",
"src/heap/cppgc/compaction-worklists.cc",
"src/heap/cppgc/compaction-worklists.h",
"src/heap/cppgc/compactor.cc",
"src/heap/cppgc/compactor.h",
"src/heap/cppgc/concurrent-marker.cc",
"src/heap/cppgc/concurrent-marker.h",
"src/heap/cppgc/explicit-management.cc",
"src/heap/cppgc/free-list.cc",
"src/heap/cppgc/free-list.h",
"src/heap/cppgc/garbage-collector.h",
"src/heap/cppgc/gc-info.cc",
"src/heap/cppgc/gc-info-table.cc",
"src/heap/cppgc/gc-info-table.h",
"src/heap/cppgc/gc-invoker.cc",
"src/heap/cppgc/gc-invoker.h",
"src/heap/cppgc/globals.h",
"src/heap/cppgc/heap.cc",
"src/heap/cppgc/heap.h",
"src/heap/cppgc/heap-base.cc",
"src/heap/cppgc/heap-base.h",
"src/heap/cppgc/heap-config.h",
"src/heap/cppgc/heap-consistency.cc",
"src/heap/cppgc/heap-growing.cc",
"src/heap/cppgc/heap-growing.h",
"src/heap/cppgc/heap-object-header.cc",
"src/heap/cppgc/heap-object-header.h",
"src/heap/cppgc/heap-page.cc",
"src/heap/cppgc/heap-page.h",
"src/heap/cppgc/heap-space.cc",
"src/heap/cppgc/heap-space.h",
"src/heap/cppgc/heap-state.cc",
"src/heap/cppgc/heap-statistics-collector.cc",
"src/heap/cppgc/heap-statistics-collector.h",
"src/heap/cppgc/heap-visitor.h",
"src/heap/cppgc/liveness-broker.cc",
"src/heap/cppgc/liveness-broker.h",
"src/heap/cppgc/logging.cc",
"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",
"src/heap/cppgc/marking-visitor.cc",
"src/heap/cppgc/marking-visitor.h",
"src/heap/cppgc/marking-worklists.cc",
"src/heap/cppgc/marking-worklists.h",
"src/heap/cppgc/member-storage.cc",
"src/heap/cppgc/member-storage.h",
"src/heap/cppgc/memory.cc",
"src/heap/cppgc/memory.h",
"src/heap/cppgc/metric-recorder.h",
"src/heap/cppgc/name-trait.cc",
"src/heap/cppgc/object-allocator.cc",
"src/heap/cppgc/object-allocator.h",
"src/heap/cppgc/object-poisoner.h",
"src/heap/cppgc/object-size-trait.cc",
"src/heap/cppgc/object-start-bitmap.h",
"src/heap/cppgc/object-view.h",
"src/heap/cppgc/page-memory.cc",
"src/heap/cppgc/page-memory.h",
"src/heap/cppgc/persistent-node.cc",
"src/heap/cppgc/platform.cc",
"src/heap/cppgc/platform.h",
"src/heap/cppgc/pointer-policies.cc",
"src/heap/cppgc/prefinalizer-handler.cc",
"src/heap/cppgc/prefinalizer-handler.h",
"src/heap/cppgc/process-heap.cc",
"src/heap/cppgc/process-heap.h",
"src/heap/cppgc/process-heap-statistics.cc",
"src/heap/cppgc/process-heap-statistics.h",
"src/heap/cppgc/raw-heap.cc",
"src/heap/cppgc/raw-heap.h",
"src/heap/cppgc/remembered-set.cc",
"src/heap/cppgc/remembered-set.h",
"src/heap/cppgc/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/unmarker.h",
"src/heap/cppgc/virtual-memory.cc",
"src/heap/cppgc/virtual-memory.h",
"src/heap/cppgc/visitor.cc",
"src/heap/cppgc/visitor.h",
"src/heap/cppgc/write-barrier.cc",
"src/heap/cppgc/write-barrier.h",
"src/heap/cppgc-internal/allocation.cc",
"src/heap/cppgc-internal/caged-heap.h",
"src/heap/cppgc-internal/compaction-worklists.cc",
"src/heap/cppgc-internal/compaction-worklists.h",
"src/heap/cppgc-internal/compactor.cc",
"src/heap/cppgc-internal/compactor.h",
"src/heap/cppgc-internal/concurrent-marker.cc",
"src/heap/cppgc-internal/concurrent-marker.h",
"src/heap/cppgc-internal/explicit-management.cc",
"src/heap/cppgc-internal/free-list.cc",
"src/heap/cppgc-internal/free-list.h",
"src/heap/cppgc-internal/garbage-collector.h",
"src/heap/cppgc-internal/gc-info.cc",
"src/heap/cppgc-internal/gc-info-table.cc",
"src/heap/cppgc-internal/gc-info-table.h",
"src/heap/cppgc-internal/gc-invoker.cc",
"src/heap/cppgc-internal/gc-invoker.h",
"src/heap/cppgc-internal/globals.h",
"src/heap/cppgc-internal/heap.cc",
"src/heap/cppgc-internal/heap.h",
"src/heap/cppgc-internal/heap-base.cc",
"src/heap/cppgc-internal/heap-base.h",
"src/heap/cppgc-internal/heap-config.h",
"src/heap/cppgc-internal/heap-consistency.cc",
"src/heap/cppgc-internal/heap-growing.cc",
"src/heap/cppgc-internal/heap-growing.h",
"src/heap/cppgc-internal/heap-object-header.cc",
"src/heap/cppgc-internal/heap-object-header.h",
"src/heap/cppgc-internal/heap-page.cc",
"src/heap/cppgc-internal/heap-page.h",
"src/heap/cppgc-internal/heap-space.cc",
"src/heap/cppgc-internal/heap-space.h",
"src/heap/cppgc-internal/heap-state.cc",
"src/heap/cppgc-internal/heap-statistics-collector.cc",
"src/heap/cppgc-internal/heap-statistics-collector.h",
"src/heap/cppgc-internal/heap-visitor.h",
"src/heap/cppgc-internal/liveness-broker.cc",
"src/heap/cppgc-internal/liveness-broker.h",
"src/heap/cppgc-internal/logging.cc",
"src/heap/cppgc-internal/marker.cc",
"src/heap/cppgc-internal/marker.h",
"src/heap/cppgc-internal/marking-state.cc",
"src/heap/cppgc-internal/marking-state.h",
"src/heap/cppgc-internal/marking-verifier.cc",
"src/heap/cppgc-internal/marking-verifier.h",
"src/heap/cppgc-internal/marking-visitor.cc",
"src/heap/cppgc-internal/marking-visitor.h",
"src/heap/cppgc-internal/marking-worklists.cc",
"src/heap/cppgc-internal/marking-worklists.h",
"src/heap/cppgc-internal/member-storage.cc",
"src/heap/cppgc-internal/member-storage.h",
"src/heap/cppgc-internal/memory.cc",
"src/heap/cppgc-internal/memory.h",
"src/heap/cppgc-internal/metric-recorder.h",
"src/heap/cppgc-internal/name-trait.cc",
"src/heap/cppgc-internal/object-allocator.cc",
"src/heap/cppgc-internal/object-allocator.h",
"src/heap/cppgc-internal/object-poisoner.h",
"src/heap/cppgc-internal/object-size-trait.cc",
"src/heap/cppgc-internal/object-start-bitmap.h",
"src/heap/cppgc-internal/object-view.h",
"src/heap/cppgc-internal/page-memory.cc",
"src/heap/cppgc-internal/page-memory.h",
"src/heap/cppgc-internal/persistent-node.cc",
"src/heap/cppgc-internal/platform.cc",
"src/heap/cppgc-internal/platform.h",
"src/heap/cppgc-internal/pointer-policies.cc",
"src/heap/cppgc-internal/prefinalizer-handler.cc",
"src/heap/cppgc-internal/prefinalizer-handler.h",
"src/heap/cppgc-internal/process-heap.cc",
"src/heap/cppgc-internal/process-heap.h",
"src/heap/cppgc-internal/process-heap-statistics.cc",
"src/heap/cppgc-internal/process-heap-statistics.h",
"src/heap/cppgc-internal/raw-heap.cc",
"src/heap/cppgc-internal/raw-heap.h",
"src/heap/cppgc-internal/remembered-set.cc",
"src/heap/cppgc-internal/remembered-set.h",
"src/heap/cppgc-internal/stats-collector.cc",
"src/heap/cppgc-internal/stats-collector.h",
"src/heap/cppgc-internal/sweeper.cc",
"src/heap/cppgc-internal/sweeper.h",
"src/heap/cppgc-internal/task-handle.h",
"src/heap/cppgc-internal/trace-event.h",
"src/heap/cppgc-internal/trace-trait.cc",
"src/heap/cppgc-internal/unmarker.h",
"src/heap/cppgc-internal/virtual-memory.cc",
"src/heap/cppgc-internal/virtual-memory.h",
"src/heap/cppgc-internal/visitor.cc",
"src/heap/cppgc-internal/visitor.h",
"src/heap/cppgc-internal/write-barrier.cc",
"src/heap/cppgc-internal/write-barrier.h",
],
)
@@ -4112,24 +4198,20 @@ filegroup(
name = "v8_bigint",
srcs = [
"src/bigint/bigint.h",
"src/bigint/bigint-inl.h",
"src/bigint/bigint-internal.cc",
"src/bigint/bigint-internal.h",
"src/bigint/bitwise.cc",
"src/bigint/digit-arithmetic.h",
"src/bigint/div-barrett.cc",
"src/bigint/div-burnikel.cc",
"src/bigint/div-helpers.cc",
"src/bigint/div-helpers.h",
"src/bigint/div-helpers-inl.h",
"src/bigint/div-schoolbook.cc",
"src/bigint/fromstring.cc",
"src/bigint/mul-fft.cc",
"src/bigint/mul-karatsuba.cc",
"src/bigint/mul-schoolbook.cc",
"src/bigint/mul-toom.cc",
"src/bigint/tostring.cc",
"src/bigint/util.h",
"src/bigint/vector-arithmetic.cc",
"src/bigint/vector-arithmetic.h",
"src/bigint/vector-arithmetic-inl.h",
],
)
@@ -4359,23 +4441,15 @@ v8_torque_files(
"exported-macros-assembler.h",
],
definition_extras = [
"bit-fields.h",
"bit-field-asserts.cc",
"builtin-definitions.h",
# "class-debug-readers.cc",
# "class-debug-readers.h",
"class-forward-declarations.h",
"class-verifiers.cc",
"class-verifiers.h",
# "debug-macros.cc",
# "debug-macros.h",
"factory.cc",
"factory.inc",
"instance-types.h",
"interface-descriptors.inc",
"objects-body-descriptors-inl.inc",
"objects-printer.cc",
"visitor-lists.h",
],
icu_srcs = [":icu/torque_files"],
noicu_srcs = [":noicu/torque_files"],
@@ -4471,6 +4545,8 @@ filegroup(
"src/d8/d8-test.cc",
"src/d8/hardware-watchpoints.cc",
"src/d8/hardware-watchpoints.h",
"src/d8/memory-access-information.cc",
"src/d8/memory-access-information.h",
],
)
@@ -4533,6 +4609,13 @@ cc_library(
strip_include_prefix = "noicu",
)
cc_library(
name = "llvm_libc_headers",
hdrs = glob(["third_party/llvm-libc/src/shared/**/*.h"]),
includes = ["third_party/llvm-libc/src"],
defines = ["LIBC_NAMESPACE=__llvm_libc_cr"],
)
v8_library(
name = "v8_libbase",
srcs = [
@@ -4541,6 +4624,7 @@ v8_library(
],
copts = ["-Wno-implicit-fallthrough"],
deps = [
":llvm_libc_headers",
"@abseil-cpp//absl/synchronization",
"@abseil-cpp//absl/time",
"@abseil-cpp//absl/functional:overload",
@@ -4571,6 +4655,8 @@ cc_library(
deps = [
":torque_base_headers",
":v8_libbase",
"@abseil-cpp//absl/container:node_hash_map",
"@abseil-cpp//absl/container:node_hash_set",
],
)
@@ -4578,7 +4664,6 @@ cc_library(
name = "simdutf",
srcs = ["third_party/simdutf/simdutf.cpp"],
hdrs = ["third_party/simdutf/simdutf.h"],
strip_include_prefix = "third_party/simdutf",
copts = select({
"@v8//bazel/config:is_clang": ["-std=c++20"],
"@v8//bazel/config:is_gcc": ["-std=gnu++2a"],
@@ -4743,7 +4828,11 @@ v8_binary(
"@v8//bazel/config:is_android": ["-llog"],
"//conditions:default": [],
}),
deps = ["v8_libbase"],
deps = [
"v8_libbase",
"@abseil-cpp//absl/container:node_hash_map",
"@abseil-cpp//absl/container:node_hash_set",
],
)
v8_binary(
@@ -4823,7 +4912,7 @@ py_test(
args = [
"--no-sorting",
"--nopresubmit",
"--variant=google3_noicu",
"--variant=google3",
"--outdir noicu",
"--verbose",
] + select({
@@ -4861,7 +4950,7 @@ py_test(
args = [
"--no-sorting",
"--nopresubmit",
"--variant=google3_icu",
"--variant=google3",
"--outdir icu",
"--verbose",
] + select({
@@ -4887,3 +4976,41 @@ py_test(
"nosan",
],
)
py_test(
name = "icu/intl",
size = "medium",
srcs = [
"test/intl/testcfg.py",
"tools/predictable_wrapper.py",
"tools/run-tests.py",
] + glob(["tools/testrunner/**/*.py"]),
args = [
"--no-sorting",
"--nopresubmit",
"--variant=google3",
"--outdir icu",
"--verbose",
] + select({
"@v8//bazel/config:v8_target_arm64": [
"--arch=arm64",
],
"@v8//bazel/config:v8_target_x64": [
"--arch=x64",
],
"//conditions:default": [],
}) + [
"intl",
],
data = [
"test",
":icu/d8",
":icu/v8_build_config",
"//testing/pybase",
] + glob(["test/**"]) + glob(["tools/**/*.js"]) + glob(["tools/**/*.mjs"]),
main = "tools/run-tests.py",
tags = [
# Disable sanitizers, as they don't work in general in V8.
"nosan",
],
)
deps/v8/BUILD.gn
Vendored
+599 -316
View File
File diff suppressed because it is too large. Load diff
deps/v8/COMMON_OWNERS
Vendored
+1 -1
View File
@@ -9,7 +9,6 @@ dlehmann@chromium.org
dmercadier@chromium.org
ecmziegler@chromium.org
emaxx@google.com
evih@chromium.org
fgm@chromium.org
gdeepti@chromium.org
hpayer@chromium.org
@@ -23,6 +22,7 @@ manoskouk@chromium.org
marja@chromium.org
mliedtke@chromium.org
mlippautz@chromium.org
mrcvtl@chromium.org
nicohartmann@chromium.org
nikolaos@chromium.org
olivf@chromium.org
deps/v8/DEPS
Vendored
+205 -149
View File
@@ -6,10 +6,15 @@ use_relative_paths = True
gclient_gn_args_file = 'build/config/gclient_args.gni'
gclient_gn_args = [
'android_ndk_version',
'checkout_src_internal',
]
vars = {
# The version of the NDK. Set here, to allow the autoroller to update this
# value when updating the CIPD hash.
'android_ndk_version': Str('2@30.0.15729638'),
# Fetches only the SDK boot images which match at least one of the whitelist
# entries in a comma-separated list.
#
@@ -30,6 +35,11 @@ vars = {
'checkout_instrumented_libraries': False,
'checkout_ittapi': False,
# Checkout extra benchmarks.
'checkout_benchmarks': False,
# Fetch the internal v8 perf repository for additional benchmarks.
'checkout_v8_perf': False,
# Fetch the prebuilt binaries for llvm-cov and llvm-profdata. Needed to
# process the raw profiles produced by instrumented targets (built with
@@ -47,6 +57,7 @@ vars = {
'android_url': 'https://android.googlesource.com',
'chromium_url': 'https://chromium.googlesource.com',
'chrome_internal_url': 'https://chrome-internal.googlesource.com',
'download_gcmole': False,
'download_jsfunfuzz': False,
'download_prebuilt_bazel': False,
@@ -62,6 +73,9 @@ vars = {
# V8 doesn't need src_internal, but some shared GN files use this variable.
'checkout_src_internal': False,
# Fetch the internal agents repository.
'checkout_agents_internal': False,
# reclient CIPD package version
'reclient_version': 're_client_version:0.185.0.db415f21-gomaip',
@@ -78,30 +92,33 @@ vars = {
# This variable is overrided in Chromium's DEPS file.
'build_with_chromium': False,
# Repository URL
'chromium_jetstream_git': 'https://chromium.googlesource.com/external/github.com/WebKit/JetStream.git',
# GN CIPD package version.
'gn_version': 'git_revision:103f8b437f5e791e0aef9d5c372521a5d675fabb',
'gn_version': 'git_revision:641ace93dd9560e75e7add0d08f77b446fbb3b78',
# ninja CIPD package version
# https://chrome-infra-packages.appspot.com/p/infra/3pp/tools/ninja
'ninja_version': 'version:3@1.12.1.chromium.4',
# siso CIPD package version
'siso_version': 'git_revision:dc540b292de5e5cbfc88bbdd15b30b1634979823',
'siso_version': 'git_revision:78c72819a5567e09f4b3083b04c6b15d11bb345b',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling Fuchsia sdk
# and whatever else without interference from each other.
'fuchsia_version': 'version:30.20251218.4.1',
'fuchsia_version': 'version:32.20260723.5.1',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling partition_alloc_version
# and whatever else without interference from each other.
'partition_alloc_version': '936619c71ecb17c0e2482cf86be3f3f417b2f683',
'partition_alloc_version': '66df8ef636795eff70efc52a47d8f62612800054',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling android_sdk_build-tools_version
# and whatever else without interference from each other.
'android_sdk_build-tools_version': '-jLl4Ibk_WmgTsZaP-ueQwZDhBwkWf5BsQ4UNrkzXF0C',
'android_sdk_build-tools_version': 'febJrTgiK9s1ANoUlc4Orn3--zs9GjGCj2vQc8g7OaMC',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling android_sdk_emulator_version
# and whatever else without interference from each other.
@@ -113,18 +130,37 @@ vars = {
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling android_sdk_platforms_version
# and whatever else without interference from each other.
'android_sdk_platforms_version': 'gxwLT70eR_ObwZJzKK8UIS-N549yAocNTmc0JHgO7gUC',
'android_sdk_platforms_version': 'WhtP32Q46ZHdTmgCgdauM3ws_H9iPoGKEZ_cPggcQ6wC',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling android_sdk_tools-lint_version
# and whatever else without interference from each other.
'android_sdk_cmdline-tools_version': 'gekOVsZjseS1w9BXAT3FsoW__ByGDJYS9DgqesiwKYoC',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling jetstream_3.0-custom_revision
# and whatever else without interference from each other.
'jetstream_3.0-custom_revision': '91552391bf2f429a2b7102c5c02d6f2cb82b4bcf',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling agents-internal
# and whatever else without interference from each other.
'agents_internal_revision': '21c25488408500557636122892d27dda39a0f922',
# Three lines of non-changing comments so that
# the commit queue can handle CLs rolling agents-public
# and whatever else without interference from each other.
'agents_public_revision': '559f135fc214d637f85174c6be7010804e31f1e5',
}
deps = {
'agents/shared': {
'url': Var('chromium_url') + '/chromium/agents.git' + '@' + Var('agents_public_revision'),
},
'agents/internal': {
'url': Var('chrome_internal_url') + '/chrome/agents-internal.git' + '@' + Var('agents_internal_revision'),
'condition': 'checkout_agents_internal',
},
'build':
Var('chromium_url') + '/chromium/src/build.git' + '@' + '483cecced32ce8b098d65eb08eb77925afa90bec',
Var('chromium_url') + '/chromium/src/build.git' + '@' + 'fab0ea1e4e8033be4088e2478d58cfac471b76ca',
'buildtools':
Var('chromium_url') + '/chromium/src/buildtools.git' + '@' + '6a18683f555b4ac8b05ac8395c29c84483ac9588',
Var('chromium_url') + '/chromium/src/buildtools.git' + '@' + '0d8a204ff274ee12fa9ace5e3ffd8e5fbcb54926',
'buildtools/linux64': {
'packages': [
{
@@ -165,12 +201,21 @@ deps = {
'dep_type': 'cipd',
'condition': '(host_os == "linux" or host_os == "mac" or host_os == "win") and host_cpu != "s390x" and host_os != "zos" and host_cpu != "ppc64" and (host_cpu != "arm64" or host_os == "mac")',
},
# TODO(498118202): Use checkout_benchmarks here too.
'test/benchmarks/data':
Var('chromium_url') + '/v8/deps/third_party/benchmarks.git' + '@' + '05d7188267b4560491ff9155c5ee13e207ecd65f',
'test/benchmarks/JetStream3': {
'url': Var('chromium_jetstream_git') + '@' + Var('jetstream_3.0-custom_revision'),
'condition': 'checkout_benchmarks',
},
'third_party/v8-perf': {
'url': Var('chrome_internal_url') + '/v8/v8-perf.git' + '@' + 'HEAD',
'condition': 'checkout_v8_perf',
},
'test/mozilla/data':
Var('chromium_url') + '/v8/deps/third_party/mozilla-tests.git' + '@' + 'f6c578a10ea707b1a8ab0b88943fe5115ce2b9be',
'test/test262/data':
Var('chromium_url') + '/external/github.com/tc39/test262.git' + '@' + 'dd6138f9bc1aa2c3ba9cbf54452049b9a92c4e13',
Var('chromium_url') + '/external/github.com/tc39/test262.git' + '@' + '9e61c12835c5e4a3bdba93850427e6742c4f64c4',
'third_party/android_platform': {
'url': Var('chromium_url') + '/chromium/src/third_party/android_platform.git' + '@' + 'e3919359f2387399042d31401817db4a02d756ec',
'condition': 'checkout_android',
@@ -178,7 +223,7 @@ deps = {
'third_party/android_sdk/public': {
'packages': [
{
'package': 'chromium/third_party/android_sdk/public/build-tools/36.1.0',
'package': 'chromium/third_party/android_sdk/public/build-tools/37.0.0',
'version': Var('android_sdk_build-tools_version'),
},
{
@@ -190,7 +235,7 @@ deps = {
'version': Var('android_sdk_platform-tools_version'),
},
{
'package': 'chromium/third_party/android_sdk/public/platforms/android-36.1',
'package': 'chromium/third_party/android_sdk/public/platforms/android-37.0',
'version': Var('android_sdk_platforms_version'),
},
{
@@ -205,40 +250,44 @@ deps = {
'packages': [
{
'package': 'chromium/third_party/android_toolchain/android_toolchain',
'version': 'KXOia11cm9lVdUdPlbGLu8sCz6Y4ey_HV2s8_8qeqhgC',
'version': 'version:' + Var('android_ndk_version'),
},
],
'condition': 'checkout_android',
'dep_type': 'cipd',
},
'third_party/catapult': {
'url': Var('chromium_url') + '/catapult.git' + '@' + 'ef2533747d649df4cba6756528f68751b8523f81',
'url': Var('chromium_url') + '/catapult.git' + '@' + '74513188f5cd39f9edb16236ea3a49ed5b3cb3c6',
'condition': 'checkout_android',
},
'third_party/clang-format/script':
Var('chromium_url') + '/external/github.com/llvm/llvm-project/clang/tools/clang-format.git' + '@' + 'c2725e0622e1a86d55f14514f2177a39efea4a0e',
Var('chromium_url') + '/external/github.com/llvm/llvm-project/clang/tools/clang-format.git' + '@' + '6eddfb5ec5f92127a531eda66c568d3a11e7ec11',
'third_party/colorama/src': {
'url': Var('chromium_url') + '/external/colorama.git' + '@' + '3de9f013df4b470069d03d250224062e8cf15c49',
'condition': 'checkout_android',
},
'third_party/cpu_features': {
'url': Var('chromium_url') + '/chromium/src/third_party/cpu_features.git' + '@' + '4974e2063946d9dd2a417c27db139fd982ff447a',
'condition': 'checkout_android',
},
'third_party/cpu_features/src': {
'url': Var('chromium_url') + '/external/github.com/google/cpu_features.git' + '@' + '936b9ab5515dead115606559502e3864958f7f6e',
'url': Var('chromium_url') + '/external/github.com/google/cpu_features.git' + '@' + '81d13c49649f0714dd41fb56bb246398b6584085',
'condition': 'checkout_android',
},
'third_party/depot_tools':
Var('chromium_url') + '/chromium/tools/depot_tools.git' + '@' + '284c5ccb591c3de4e9f71be4a4beb5d1916d5383',
Var('chromium_url') + '/chromium/tools/depot_tools.git' + '@' + 'f394ab2c993283e94680ca13db98b99927868e98',
'third_party/dragonbox/src':
Var('chromium_url') + '/external/github.com/jk-jeon/dragonbox.git' + '@' + 'beeeef91cf6fef89a4d4ba5e95d47ca64ccb3a44',
'third_party/fp16/src':
Var('chromium_url') + '/external/github.com/Maratyszcza/FP16.git' + '@' + '3d2de1816307bac63c16a297e8c4dc501b4076df',
Var('chromium_url') + '/external/github.com/Maratyszcza/FP16.git' + '@' + '782eea126dc5c755827be751a099eb01826175cf',
'third_party/fast_float/src':
Var('chromium_url') + '/external/github.com/fastfloat/fast_float.git' + '@' + 'cb1d42aaa1e14b09e1452cfdef373d051b8c02a4',
Var('chromium_url') + '/external/github.com/fastfloat/fast_float.git' + '@' + '34164f547b7df3f5d794ff67e9f885c36819ebfc',
'third_party/fuchsia-gn-sdk': {
'url': Var('chromium_url') + '/chromium/src/third_party/fuchsia-gn-sdk.git' + '@' + '947109b3f1f40fb060e7c91df049ee53fe89d573',
'url': Var('chromium_url') + '/chromium/src/third_party/fuchsia-gn-sdk.git' + '@' + '4f34a41435a29fbf91cb3c6e0bcaffff6598c190',
'condition': 'checkout_fuchsia',
},
'third_party/simdutf':
Var('chromium_url') + '/chromium/src/third_party/simdutf' + '@' + '93b35aec29256f705c97f675fe4623578bd7a395',
Var('chromium_url') + '/chromium/src/third_party/simdutf' + '@' + 'f7356eed293f8208c40b3c1b344a50bd70971983',
# Exists for rolling the Fuchsia SDK. Check out of the SDK should always
# rely on the hook running |update_sdk.py| script below.
'third_party/fuchsia-sdk/sdk': {
@@ -252,23 +301,23 @@ deps = {
'dep_type': 'cipd',
},
'third_party/google_benchmark_chrome': {
'url': Var('chromium_url') + '/chromium/src/third_party/google_benchmark.git' + '@' + 'abeba5d5e6db5bdf85261045e148f1db3fdc40ad',
'url': Var('chromium_url') + '/chromium/src/third_party/google_benchmark.git' + '@' + 'c3b654389bf74fac1f2d926d0439506f06c66751',
},
'third_party/google_benchmark_chrome/src': {
'url': Var('chromium_url') + '/external/github.com/google/benchmark.git' + '@' + '188e8278990a9069ffc84441cb5a024fd0bede37',
'url': Var('chromium_url') + '/external/github.com/google/benchmark.git' + '@' + '8abf1e701fbd88c8170f48fe0558247e2e5f8e7d',
},
'third_party/fuzztest':
Var('chromium_url') + '/chromium/src/third_party/fuzztest.git' + '@' + '3c8b741ed69e60949a481e3ff86c7933f65cfc2d',
Var('chromium_url') + '/chromium/src/third_party/fuzztest.git' + '@' + 'cc30588369ddfd00e2098229ea8050a8ebe1cf58',
'third_party/fuzztest/src':
Var('chromium_url') + '/external/github.com/google/fuzztest.git' + '@' + '54dfec04d5c9ad1f22b08002ab6a5e2d0de77671',
Var('chromium_url') + '/external/github.com/google/fuzztest.git' + '@' + '073bf2392bf11e22d456036a8f7d286bc9a6d346',
'third_party/googletest/src':
Var('chromium_url') + '/external/github.com/google/googletest.git' + '@' + '4fe3307fb2d9f86d19777c7eb0e4809e9694dde7',
'third_party/highway/src':
Var('chromium_url') + '/external/github.com/google/highway.git' + '@' + '84379d1c73de9681b54fbe1c035a23c7bd5d272d',
Var('chromium_url') + '/external/github.com/google/highway.git' + '@' + '2607d3b5b0113992fe84d3848859eae13b3b52c1',
'third_party/icu':
Var('chromium_url') + '/chromium/deps/icu.git' + '@' + 'a86a32e67b8d1384b33f8fa48c83a6079b86f8cd',
Var('chromium_url') + '/chromium/deps/icu.git' + '@' + 'd578f2e8b7bd5938e21cfb6bf15c079e0aa5b738',
'third_party/instrumented_libs': {
'url': Var('chromium_url') + '/chromium/third_party/instrumented_libraries.git' + '@' + '69015643b3f68dbd438c010439c59adc52cac808',
'url': Var('chromium_url') + '/chromium/third_party/instrumented_libraries.git' + '@' + 'e8cb570a9a2ee9128e2214c73417ad2a3c47780b',
'condition': 'checkout_instrumented_libraries',
},
'third_party/ittapi': {
@@ -280,181 +329,181 @@ deps = {
'third_party/jinja2':
Var('chromium_url') + '/chromium/src/third_party/jinja2.git' + '@' + 'c3027d884967773057bf74b957e3fea87e5df4d7',
'third_party/jsoncpp/source':
Var('chromium_url') + '/external/github.com/open-source-parsers/jsoncpp.git'+ '@' + '42e892d96e47b1f6e29844cc705e148ec4856448',
Var('chromium_url') + '/external/github.com/open-source-parsers/jsoncpp.git'+ '@' + 'edc01ab10f52135ec80e3589b6b4e0a9c65b27fd',
'third_party/libc++/src':
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libcxx.git' + '@' + '7ab65651aed6802d2599dcb7a73b1f82d5179d05',
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libcxx.git' + '@' + 'b16984ce99c702355a5b2b4c52574e82cec41fb9',
'third_party/libc++abi/src':
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libcxxabi.git' + '@' + '8f11bb1d4438d0239d0dfc1bd9456a9f31629dda',
'third_party/libpfm4':
Var('chromium_url') + '/chromium/src/third_party/libpfm4.git' + '@' + '25c29f04c9127e1ca09e6c1181f74850aa7f118b',
Var('chromium_url') + '/chromium/src/third_party/libpfm4.git' + '@' + '4a112befd93f8d90a9b6894b2ec4d320310e1178',
'third_party/libpfm4/src':
Var('chromium_url') + '/external/git.code.sf.net/p/perfmon2/libpfm4.git' + '@' + '964baf9d35d5f88d8422f96d8a82c672042e7064',
Var('chromium_url') + '/external/git.code.sf.net/p/perfmon2/libpfm4.git' + '@' + '6870a9f00412830ceaa7e4384bb92ee323e2a28f',
'third_party/libunwind/src':
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libunwind.git' + '@' + 'ba19d93d6d4f467fba11ff20fe2fc7c056f79345',
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libunwind.git' + '@' + '1fd455816c724182cf8736811182bf0c37b03035',
'third_party/llvm-libc/src':
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libc.git' + '@' + 'e81e859cfb7e78e70a58c3bfce859c509f45e1da',
Var('chromium_url') + '/external/github.com/llvm/llvm-project/libc.git' + '@' + '75ae50cd48c8a9d70f552ccff040029968778da9',
'third_party/llvm-build/Release+Asserts': {
'dep_type': 'gcs',
'bucket': 'chromium-browser-clang',
'objects': [
{
'object_name': 'Linux_x64/clang-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '1c3c056427ab0db261c54c8fdf7c8404ff55e3de3e550520bcb1e1660ca05aad',
'size_bytes': 57489092,
'generation': 1768590901063677,
'object_name': 'Linux_x64/clang-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': 'e22e06c05fe1657f48f988b15804b8226e691addb00abba5b984a5c99ac98c42',
'size_bytes': 59093892,
'generation': 1781627382446731,
'condition': 'host_os == "linux"',
},
{
'object_name': 'Linux_x64/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'e3f568bd57c7ab199eb384153eea8cbe3c0e0604b2d8bbb158985647709a9a9c',
'size_bytes': 14391456,
'generation': 1768590901188932,
'object_name': 'Linux_x64/clang-tidy-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '96da04c2fff4e580ac81b840405edfa292108d0b593927a10750c0a1d8599c0a',
'size_bytes': 14808648,
'generation': 1781627382496605,
'condition': 'host_os == "linux" and checkout_clang_tidy',
},
{
'object_name': 'Linux_x64/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '8762f3c6102eae568e3ca7a287e774514846f2bb2feda4cf7dc1c33d9f5f1c8d',
'size_bytes': 14588900,
'generation': 1768590901246745,
'object_name': 'Linux_x64/clangd-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '1e6b6918bb270659ef517a3e8f80af8f371bc79a9d942241978db8faea22f152',
'size_bytes': 15001372,
'generation': 1781627382490030,
'condition': 'host_os == "linux" and checkout_clangd',
},
{
'object_name': 'Linux_x64/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '4705feac592251ad0e2e1c41c855a6ecdc728908cbb459d4f68ca57f16bc4c5e',
'size_bytes': 2321652,
'generation': 1768590901407256,
'object_name': 'Linux_x64/llvm-code-coverage-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': 'bb63e33c20329c344a9dfa958f3742b316c0b9dd602647190fb0037d8d53a7e6',
'size_bytes': 2332356,
'generation': 1781627382888550,
'condition': 'host_os == "linux" and checkout_clang_coverage_tools',
},
{
'object_name': 'Linux_x64/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '39d29ab3e708bcb6485181ac03123cfa3bac5b2365d5c441ab0cf5e7b25354b6',
'size_bytes': 5802908,
'generation': 1768590901316435,
'object_name': 'Linux_x64/llvmobjdump-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': 'e43b98bce71d58bbe1b456f7b62997c4d017cf8362a0367592428ac5a7512f41',
'size_bytes': 5875704,
'generation': 1781627382574869,
'condition': '(checkout_linux or checkout_mac or checkout_android) and host_os == "linux"',
},
{
'object_name': 'Mac/clang-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '9aff2c8f9d941be0667dc3ad3d4c3591dccd70f7a3b8e80396a623364e752eeb',
'size_bytes': 54613288,
'generation': 1768590902935296,
'object_name': 'Mac/clang-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '84b3934db2fb3c2e657d4a783a83ca6d2facaf598991490ae8ab712fcb03224b',
'size_bytes': 56083264,
'generation': 1781627385112611,
'condition': 'host_os == "mac" and host_cpu == "x64"',
},
{
'object_name': 'Mac/clang-mac-runtime-library-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '4f953afe4edebb54912719b437c78842978b0205792c069aa7529fd369d900be',
'size_bytes': 1011040,
'generation': 1768590912304306,
'object_name': 'Mac/clang-mac-runtime-library-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '5079e2ac3f0fa76e8b0218bf99a65a5439e8dcf6a750f886a355a66df34c69c1',
'size_bytes': 1010816,
'generation': 1781627394919334,
'condition': 'checkout_mac and not host_os == "mac"',
},
{
'object_name': 'Mac/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '62033f6ff5c1ea0a18ae581edfd1178f50ede19d84675eafb640d752e26b60ae',
'size_bytes': 14444752,
'generation': 1768590903234647,
'object_name': 'Mac/clang-tidy-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '1ca3dc160992d8c27765adaffcc8115aed34cdf7645a5354820e8c8b16b75dcd',
'size_bytes': 14790996,
'generation': 1781627384977799,
'condition': 'host_os == "mac" and host_cpu == "x64" and checkout_clang_tidy',
},
{
'object_name': 'Mac/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '4a0365772b4eb7fe12fe595355e645f12c72255bf3f869941f2b4e5c5e2b76da',
'size_bytes': 16398188,
'generation': 1768590903283692,
'object_name': 'Mac/clangd-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '4920275e6050dffbb81ba0210a627a61a20faa896aa50f5ecc2d765522790526',
'size_bytes': 16720488,
'generation': 1781627385229783,
'condition': 'host_os == "mac" and host_cpu == "x64" and checkout_clangd',
},
{
'object_name': 'Mac/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '1c307bb206c5fc1e79deec1d12ce4ead53fa41574729deaa6d2b3a67f9540710',
'size_bytes': 2352620,
'generation': 1768590903522922,
'object_name': 'Mac/llvm-code-coverage-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '07e8bf3354e0c086e420ab8f1f376e48c8b6207788cf30b56d1b0ad1fd4b0f12',
'size_bytes': 2372720,
'generation': 1781627385661382,
'condition': 'host_os == "mac" and host_cpu == "x64" and checkout_clang_coverage_tools',
},
{
'object_name': 'Mac/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '83767300f93707ba9a40d3d7e14f1149aaf587d5c1e3ae243be8742a008e5052',
'size_bytes': 5682364,
'generation': 1768590903341073,
'object_name': 'Mac/llvmobjdump-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '9b286eecf04996dfa82cd1434bceb19612fa0754e4390649ba8dcd846dca9c1e',
'size_bytes': 5797028,
'generation': 1781627385345493,
'condition': 'host_os == "mac" and host_cpu == "x64"',
},
{
'object_name': 'Mac_arm64/clang-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '5475c6c38a6199276ff173665a27ab608aadb3118ac34f1a75391ee6dc226798',
'size_bytes': 45585568,
'generation': 1768590913838191,
'object_name': 'Mac_arm64/clang-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': 'e96c5e31ddc2a6e841bcb0f7278ae82b3a581799904276e6f7673213c9748c27',
'size_bytes': 47058068,
'generation': 1781627397208650,
'condition': 'host_os == "mac" and host_cpu == "arm64"',
},
{
'object_name': 'Mac_arm64/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '9893644917db71d520832ea9e276a98e2051acf53458efc6834973e076c6d36e',
'size_bytes': 12429560,
'generation': 1768590913986547,
'object_name': 'Mac_arm64/clang-tidy-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '27eff49b49d393c903246d5e17ba620f62f493a8a39cb6dbdd2e3f5f06c592a2',
'size_bytes': 12835944,
'generation': 1781627397575694,
'condition': 'host_os == "mac" and host_cpu == "arm64" and checkout_clang_tidy',
},
{
'object_name': 'Mac_arm64/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'e67cfb9503c442bd29642b3a42b36c283346371b8143c81b895684df0fb09e69',
'size_bytes': 12817084,
'generation': 1768590914107805,
'object_name': 'Mac_arm64/clangd-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '9519e51006f45a797a351b616d92bff319793ab976eeb59df60901d6181f3c18',
'size_bytes': 13205948,
'generation': 1781627397237653,
'condition': 'host_os == "mac" and host_cpu == "arm64" and checkout_clangd',
},
{
'object_name': 'Mac_arm64/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '5f17c695f24eadcc51edc720a5b0b2f2cc36413552038d93ae2bf361667d780a',
'size_bytes': 1978756,
'generation': 1768590914351005,
'object_name': 'Mac_arm64/llvm-code-coverage-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '62084a5523a1c3b140166c2ed5a21bc110ceb65503f2759272a9f1feb00b503e',
'size_bytes': 2000216,
'generation': 1781627397451117,
'condition': 'host_os == "mac" and host_cpu == "arm64" and checkout_clang_coverage_tools',
},
{
'object_name': 'Mac_arm64/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '5fd7fc88f00197a710aac7dd00a2b6947d5231c53a472ed38e1af0b9088cefc3',
'size_bytes': 5418172,
'generation': 1768590914206466,
'object_name': 'Mac_arm64/llvmobjdump-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': 'b6c6c0b1b4147ba4d51603713d3ed21f88ee2f506ff07fb432b3444f1d323295',
'size_bytes': 5548680,
'generation': 1781627397409118,
'condition': 'host_os == "mac" and host_cpu == "arm64"',
},
{
'object_name': 'Win/clang-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'de6622ec6d9d22b00316c47b2eb59e6cb7dbcb2d5b59f04f18c94714d0b35066',
'size_bytes': 48839256,
'generation': 1768590925760667,
'object_name': 'Win/clang-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '9e3894b94d0d5e3d5904a559f590f12bd53aa5d1d9b6a902de2acb957825de46',
'size_bytes': 51306328,
'generation': 1781627409675428,
'condition': 'host_os == "win"',
},
{
'object_name': 'Win/clang-tidy-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'bf6f38e7f5d06c8c3eff9ba85df1ddd1006828cc72b638d22a3e7562507a8a51',
'size_bytes': 14353272,
'generation': 1768590926006423,
'object_name': 'Win/clang-tidy-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '8fa52c3d1707e73d0689aaa3c8d3789f13e85526bef029d942baf44ed980b442',
'size_bytes': 14867152,
'generation': 1781627409620988,
'condition': 'host_os == "win" and checkout_clang_tidy',
},
{
'object_name': 'Win/clang-win-runtime-library-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'ad0dc3c686f63f40a35bd7a10f90935d08bcd9d1f23549c87cbdeb8cb503250c',
'size_bytes': 2540656,
'generation': 1768590935148812,
'object_name': 'Win/clang-win-runtime-library-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': 'f925c30e1f63291662b2ad91103592208ecc4354f669c98a07e35360d2561a13',
'size_bytes': 2623388,
'generation': 1781627419134531,
'condition': 'checkout_win and not host_os == "win"',
},
{
'object_name': 'Win/clangd-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'bcf731c6ce9050067212fc4164893ce768809d73732459f2c1a0ddb8f124f5f2',
'size_bytes': 14736740,
'generation': 1768590926034327,
'object_name': 'Win/clangd-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '54042464918d992a19efed3a5f2a170e6fc2e4551884b4870650e3a3a6a03b41',
'size_bytes': 15262064,
'generation': 1781627409708803,
'condition': 'host_os == "win" and checkout_clangd',
},
{
'object_name': 'Win/llvm-code-coverage-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': 'bf86ab13e378a70f953d014cc7a37714dbaca0d8002cd638dd4d88df08231910',
'size_bytes': 2416448,
'generation': 1768590926285418,
'object_name': 'Win/llvm-code-coverage-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '7c4fbafcf2741a036d1f4058fc31b52cb5b0951e617561fc3d51b7fbe0a3044b',
'size_bytes': 2496336,
'generation': 1781627409916932,
'condition': 'host_os == "win" and checkout_clang_coverage_tools',
},
{
'object_name': 'Win/llvmobjdump-llvmorg-23-init-484-gf646b915-1.tar.xz',
'sha256sum': '3ee3ece3cf0afa3536c39b15f818e5eab1ac4408cd31ad0ad82414d3a8aa1eca',
'size_bytes': 5796552,
'generation': 1768590926109316,
'object_name': 'Win/llvmobjdump-llvmorg-23-init-19482-g53d18800-1.tar.xz',
'sha256sum': '7ea19d03f21ef59d2e511af8d9cccff20ea72deb54923557173bb46a64244fa7',
'size_bytes': 5934284,
'generation': 1781627409787893,
'condition': '(checkout_linux or checkout_mac or checkout_android) and host_os == "win"',
},
],
},
'third_party/logdog/logdog':
Var('chromium_url') + '/infra/luci/luci-py/client/libs/logdog' + '@' + '62fe96d7fd97a62f21a4665d2e71f69e9eedb04e',
Var('chromium_url') + '/infra/luci/luci-py/client/libs/logdog' + '@' + '6d8ea2699c6e78b344b2fc4956322aa2c463af10',
'third_party/markupsafe':
Var('chromium_url') + '/chromium/src/third_party/markupsafe.git' + '@' + '4256084ae14175d38a3ff7d739dca83ae49ccec6',
'third_party/ninja': {
@@ -472,9 +521,9 @@ deps = {
'condition': 'not build_with_chromium',
},
'third_party/perfetto':
Var('chromium_url') + '/external/github.com/google/perfetto.git' + '@' + '1d9994a93c6ada2fb261dc72984fa07683a6c86e',
Var('chromium_url') + '/external/github.com/google/perfetto.git' + '@' + 'bd153cb9c843f35cce632e2f21b8cd04b551576e',
'third_party/protobuf':
Var('chromium_url') + '/chromium/src/third_party/protobuf.git' + '@' + 'ddf513ccaeed6b1316bc2029b10f4436ad297324',
Var('chromium_url') + '/chromium/src/third_party/protobuf.git' + '@' + 'f4b110307a4845dfe04c4fc5458d514eb8fc7d66',
'third_party/re2/src':
Var('chromium_url') + '/external/github.com/google/re2.git' + '@' + '972a15cedd008d846f1a39b2e88ce48d7f166cbd',
'third_party/requests': {
@@ -482,41 +531,41 @@ deps = {
'condition': 'checkout_android',
},
'tools/rust':
Var('chromium_url') + '/chromium/src/tools/rust' + '@' + 'd2fadac996be252abe5077583a42970163e9f2e7',
Var('chromium_url') + '/chromium/src/tools/rust' + '@' + '9c007b63f883469648cd95ca8bbd88dd8f35a1b4',
'tools/win':
Var('chromium_url') + '/chromium/src/tools/win' + '@' + 'baacfc6d5986b07abe0503216b491e234b94ba79',
Var('chromium_url') + '/chromium/src/tools/win' + '@' + '45843c2c1e993427751e2a07f904db069dc26ad6',
'third_party/rust':
Var('chromium_url') + '/chromium/src/third_party/rust' + '@' + '975d090feeca96ede3442405f8d55a841c4652b6',
Var('chromium_url') + '/chromium/src/third_party/rust' + '@' + 'afbc96607d0e659715d803cc099607dd1737fc41',
'third_party/rust-toolchain': {
'dep_type': 'gcs',
'bucket': 'chromium-browser-clang',
'objects': [
{
'object_name': 'Linux_x64/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz',
'sha256sum': 'd31bf65845992926dc6dedce43348e48fd9140f5339c678974481a1e3b356da1',
'size_bytes': 267004352,
'generation': 1769079787385484,
'object_name': 'Linux_x64/rust-toolchain-b998449636a48e2c4a362809085b600a0174e1f2-5-llvmorg-23-init-19482-g53d18800.tar.xz',
'sha256sum': '1753392d6fe791a5ce743bfc70f45e151ee27bcccede516fb221b023f2c06a05',
'size_bytes': 274786408,
'generation': 1783367871911099,
'condition': 'host_os == "linux"',
},
{
'object_name': 'Mac/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz',
'sha256sum': '0677ec808549ab845bfdbe4ff6072d41c8b4f2c3321c68a5bf95b2577372fe34',
'size_bytes': 254470068,
'generation': 1769079789279846,
'object_name': 'Mac/rust-toolchain-b998449636a48e2c4a362809085b600a0174e1f2-5-llvmorg-23-init-19482-g53d18800.tar.xz',
'sha256sum': '6925151e70efd917156f3d50925c5bd416b9adf4ff42ca4bf73b4a6610d785d2',
'size_bytes': 262413648,
'generation': 1783367875702343,
'condition': 'host_os == "mac" and host_cpu == "x64"',
},
{
'object_name': 'Mac_arm64/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz',
'sha256sum': '5977efd99f758004492f7e75879db85642c37b3882d610092200e850475b9042',
'size_bytes': 238094236,
'generation': 1769079791037848,
'object_name': 'Mac_arm64/rust-toolchain-b998449636a48e2c4a362809085b600a0174e1f2-5-llvmorg-23-init-19482-g53d18800.tar.xz',
'sha256sum': '1765d9be3b30726f5f5ad60d8bc50ee66501220bc942019782cf423de3f7114e',
'size_bytes': 246837492,
'generation': 1783367879712419,
'condition': 'host_os == "mac" and host_cpu == "arm64"',
},
{
'object_name': 'Win/rust-toolchain-d2015e2359d5d0b154c2b192d4039f9b5711fcdc-4-llvmorg-23-init-484-gf646b915.tar.xz',
'sha256sum': '0e4bd819cae4aa322a6f8667e3ff157adfb5eadb9d0daf615d5ff8202c530e6e',
'size_bytes': 402509464,
'generation': 1769079792946462,
'object_name': 'Win/rust-toolchain-b998449636a48e2c4a362809085b600a0174e1f2-5-llvmorg-23-init-19482-g53d18800.tar.xz',
'sha256sum': 'dfa5db1cef7e75fd4d3ea5827f0c5eff3543d55d9d9982f806154e8d6b05950a',
'size_bytes': 415992772,
'generation': 1783367883448269,
'condition': 'host_os == "win"',
},
],
@@ -532,17 +581,23 @@ deps = {
'condition': 'not build_with_chromium and host_cpu != "s390x" and host_os != "zos" and host_cpu != "ppc64"',
},
'third_party/zlib':
Var('chromium_url') + '/chromium/src/third_party/zlib.git'+ '@' + '980253c1cc835c893c57b5cfc10c5b942e10bc46',
Var('chromium_url') + '/chromium/src/third_party/zlib.git'+ '@' + '42c2f19a14d33b4ed327ab898fe7b652013aa740',
'tools/clang':
Var('chromium_url') + '/chromium/src/tools/clang.git' + '@' + 'd651bc848c45c945ecbc0c1a372b0b781e47c991',
Var('chromium_url') + '/chromium/src/tools/clang.git' + '@' + '56a7ab321b6840e949e3acf5f4528dadc6cb05bc',
'tools/protoc_wrapper':
Var('chromium_url') + '/chromium/src/tools/protoc_wrapper.git' + '@' + '3438d4183bfc7c0d6850e8b970204cc8189f0323',
Var('chromium_url') + '/chromium/src/tools/protoc_wrapper.git' + '@' + '418c65786fdf6fc5f10cb008c252c2b12c4713a6',
'third_party/abseil-cpp': {
'url': Var('chromium_url') + '/chromium/src/third_party/abseil-cpp.git' + '@' + '6d5ac0f7d3f0af5d13b78044fc31c793aa3549f8',
'url': Var('chromium_url') + '/chromium/src/third_party/abseil-cpp.git' + '@' + 'ff6e8ce3e932c16cebd1611c8fc42c45080a0e55',
'condition': 'not build_with_chromium',
},
'third_party/fadec/src': {
'url': Var('chromium_url') + '/external/github.com/aengelke/fadec.git' + '@' + 'c9f78f532b9004de278489019ab2c6c28ae9746e',
},
'third_party/disarm/src': {
'url': Var('chromium_url') + '/external/github.com/aengelke/disarm.git' + '@' + '2d13d3f410a52daff1c5d8ef07d623332f372560',
},
'third_party/zoslib': {
'url': Var('chromium_url') + '/external/github.com/ibmruntimes/zoslib.git' + '@' + '1e68de6e37efced3738a88536fccb6bbfe2d70b2',
'url': Var('chromium_url') + '/external/github.com/ibmruntimes/zoslib.git' + '@' + '804b13554e8dd6972a591c1d6e532514fadd42a8',
'condition': 'host_os == "zos"',
}
}
@@ -557,10 +612,10 @@ include_rules = [
'+third_party/fp16/src/include',
'+third_party/fuzztest',
'+third_party/ittapi/include',
'+third_party/simdutf',
'+third_party/v8/codegen',
'+third_party/vtune',
'+hwy/highway.h',
'+simdutf.h',
# Abseil features are allow-listed. Please use your best judgement when adding
# to this set -- if in doubt, email v8-dev@. For general guidance, refer to
# the Chromium guidelines (though note that some requirements in V8 may be
@@ -845,4 +900,5 @@ recursedeps = [
'build',
'buildtools',
'third_party/instrumented_libs',
'third_party/v8-perf',
]
deps/v8/GEMINI.md
Vendored
-242
View File
@@ -1,242 +0,0 @@
# Gemini Workspace for V8
This is the workspace configuration for V8 when using Gemini.
Documentation can be found at https://v8.dev/docs.
## Key Commands
- **Build (Debug):** `tools/dev/gm.py quiet x64.debug tests`
- **Build (Optimized Debug):** `tools/dev/gm.py quiet x64.optdebug tests`
- **Build (Release):** `tools/dev/gm.py quiet x64.release tests`
- **Run All Tests:** `tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug`
- **Run C++ Tests:** `tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest unittests`
- **Run JavaScript Tests:** `tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug mjsunit`
- **Format Code:** `git cl format`
Some hints:
- You are an expert C++ developer.
- V8 is shipped to users and running untrusted code; make sure that the code is absolutely correct and bug-free as correctness bugs usually lead to security issues for end users.
- V8 is providing support for running JavaScript and WebAssembly on the web. As such, it is critical to aim for best possible performance when optimizing V8.
## Folder structure
- `src/`: The main source folder providing the implementation of the virtual machine. Key subdirectories include:
- `src/api/`: Implements the V8 public C++ API, as declared in `include/`.
- `src/asmjs/`: Contains V8's Asm.js pipeline, which compiles the Asm.js subset of JavaScript into WebAssembly.
- `src/ast/`: Defines the Abstract Syntax Tree (AST) used to represent parsed JavaScript, including nodes, scopes, and variables.
- `src/base/`: Provides fundamental, low-level utilities, data structures, and a platform abstraction layer for the entire V8 project.
- `src/baseline/`: Implements the Sparkplug baseline compiler, which generates machine code directly from bytecode for a fast performance boost.
- `src/bigint/`: The implementation of BigInt operations.
- `src/builtins/`: Implementation of JavaScript built-in functions (e.g., `Array.prototype.map`).
- `src/codegen/`: Code generation, including direct machine code generation via macro assemblers, higher level codegen via CodeStubAssembler, definitions of machine code metadata like safepoint tables and source position tables, and `compiler.cc` which defines entry points into the compilers. This contains subdirectories for architecture specific implementations, which should be kept in sync with each other as much as possible.
- `src/common/`: Common definitions and utilities.
- `src/compiler/`: The TurboFan optimizing compiler, including the Turboshaft CFG compiler.
- `src/d8/`: The `d8` shell implementation, for running V8 in a CLI.
- `src/debug/`: The debugger and debug protocol implementation.
- `src/deoptimizer/`: The deoptimizer implementation, which translates optimized frames into unoptimized ones.
- `src/execution/`: The definitions of the execution environment, including the Isolate, frame definitions, microtasks, stack guards, tiering, and on-stack argument handling.
- `src/handles/`: The handle implementation for GC-safe object references.
- `src/heap/`: The garbage collector and memory management code.
- `src/ic/`: The Inline Caching implementation.
- `src/init/`: The V8 initialization code.
- `src/inspector/`: The inspector protocol implementation.
- `src/interpreter/`: The Ignition bytecode compiler and interpreter.
- `src/json/`: The JSON parser and serializer.
- `src/libplatform/`: The platform abstraction layer, for task runners and worker threads.
- `src/logging/`: The logging implementation.
- `src/maglev/`: The Maglev mid-tier optimizing compiler.
- `src/numbers/`: Implementations of various numeric operations.
- `src/objects/`: The representation and behaviour of V8 internal and JavaScript objects.
- `src/parsing/`: The parser and scanner implementation.
- `src/profiler/`: The in-process profiler implementations, for heap snapshots, allocation tracking, and a sampling CPU profiler.
- `src/regexp/`: The regular expression implementation. This contains subdirectories for architecture specific implementations, which should be kept in sync with each other as much as possible.
- `src/runtime/`: C++ functions that can be called from JavaScript at runtime.
- `src/sandbox/`: The implementation of the sandbox, which is a security feature that attempts to limit V8 memory operations to be within a single guarded virtual memory allocation, such that corruptions of objects within the sandbox cannot lead to corruption of objects outside of it.
- `src/snapshot/`: The snapshot implementation, for both the startup snapshot (read-only, startup heap, and startup context), as well as the code-serializer, which generates code caches for caching of user script code.
- `src/strings/`: Implementations of string helpers, such as predicates for characters, unicode processing, hashing and string building.
- `src/torque/`: The Torque language implementation.
- `src/tracing/`: The tracing implementation.
- `src/trap-handler/`: Implementations of trap handlers.
- `src/wasm/`: The WebAssembly implementation.
- `src/zone/`: The implementation of a simple bump-pointer region-based zone allocator.
- `test/`: Folder containing most of the tests and testing code.
- `include/`: Folder containing all of V8's publicAPI that is used when V8 is embedded in other projects such as e.g. the Blink rendering engine.
- `out/`: Folder containing the results of a build. Usually organized in sub folders for the respective configurations.
## Building
The full documentation for building using GN can be found at https://v8.dev/docs/build-gn.
Once the initial dependencies are installed, V8 can be built using `gm.py`, which is a wrapper around GN and Ninja.
```bash
# List all available build configurations and targets
tools/dev/gm.py
# Build the d8 shell for x64 in release mode
tools/dev/gm.py quiet x64.release
# Build d8 for x64 in debug mode
tools/dev/gm.py quiet x64.debug
```
- **release:** Optimized for performance, with debug information stripped. Use for benchmarking.
- **debug:** Contains full debug information and enables assertions. Slower, but essential for debugging.
- **optdebug:** A compromise with optimizations enabled and debug information included. Good for general development.
Make sure to pass the `quiet` keyword unless told to otherwise, so that you don't waste tokens on compilation progress. Errors will still be reported.
## Debugging
For debugging, it is recommended to use a `debug` or `optdebug` build. You can run `d8` with GDB or LLDB for native code debugging.
```bash
# Example of running d8 with gdb
gdb --args out/x64.debug/d8 --my-flag my-script.js
```
V8 also provides a rich set of flags for diagnostics. Some of the most common ones are:
- `--trace-opt`: Log optimized functions.
- `--trace-deopt`: Log when and why functions are deoptimized.
- `--trace-gc`: Log garbage collection events.
- `--allow-natives-syntax`: Enables calling of internal V8 functions (e.g. `%OptimizeFunctionOnNextCall(f)`) from JavaScript for testing purposes.
A comprehensive list of all flags can be found by running `out/x64.debug/d8 --help`. Most V8 flags are in `flag-definitions.h`; flags specific to the `d8` shell are located in `src/d8/d8.cc` within the `Shell::SetOptions` function.
When debugging issues in Torque code, it is often useful to inspect the generated C++ files in `out/<build-config>/gen/torque-generated/`. This allows you to see the low-level CodeStubAssembler code that is actually being executed.
## Testing
The primary script for running tests is `tools/run-tests.py`. You specify the build output directory and the tests you want to run. Key test suites include:
- **unittests:** C++ unit tests for V8's internal components.
- **cctest:** Another, older format for C++ unit tests (deprecated, in the process of being moved to unittests).
- **mjsunit:** JavaScript-based tests for JavaScript language features and builtins.
```bash
# Run all standard tests for the x64.optdebug build
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug
# Run a specific test suite (e.g., cctest)
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest
# Run a specific test file
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest/test-heap
```
It's important to pass `--progress dots` so that there is minimal progress reporting, to avoid cluttering the output.
If there are any failing tests, they will be reported along their stderr and a command to reproduce them e.g.
```
=== mjsunit/maglev/regress-429656023 ===
--- stderr ---
#
# Fatal error in ../../src/heap/local-factory.h, line 41
# unreachable code
#
#
#
...stack trace...
Received signal 6
Command: out/x64.optdebug/d8 --test test/mjsunit/mjsunit.js test/mjsunit/maglev/regress-429656023.js --random-seed=-190258694 --nohard-abort --verify-heap --allow-natives-syntax
```
You can retry the test either by running the test name with `tools/run-tests.py`, e.g. `tools/run-tests.py --progress dots --outdir=out/x64.optdebug mjsunit/maglev/regress-429656023`, or by running the command directly. When running the command directly, you can add additional flags to help debug the issue, and you can try running a different build (e.g. running a debug build if a release build fails).
The full testing documentation is at https://v8.dev/docs/test.
## Coding and Committing
- Always follow the style conventions used in code surrounding your changes.
- Otherwise, follow [Chromium's C++ style guide](https://chromium.googlesource.com/chromium/src/+/main/styleguide/styleguide.md).
- Use `git cl format` to automatically format your changes.
### Commit Messages
Commit messages should follow the convention described at https:/v8.dev/docs/contribute#commit-messages. A typical format is:
```
[component]: Short description of the change
Longer description explaining the "why" of the change, not just
the "what". Wrap lines at 72 characters.
Bug: 123456
```
- The `component` is the area of the codebase (e.g., `compiler`, `runtime`, `api`).
- The `Bug:` line is important for linking to issues in the tracker at https://crbug.com/
## Working with Torque
Torque is a V8-specific language used to write V8 builtins and some V8 object definitions. It provides a higher-level syntax that compiles down to CSA code.
### Key Concepts
- **Purpose:** Simplify the creation of V8 builtins and object definitions by providing a more abstract language than writing CodeStubAssembler code directly.
- **File Extension:** `.tq`
- **Location:** Torque files are primarily located in `src/builtins` and `src/objects`.
- **Compilation:** Torque files are compiled by the `torque` compiler, which generates C++ and Code Stub Assembler (CSA) files. These generated files are placed in the `out/<build-config>/gen/torque-generated/` directory and then compiled as part of the normal V8 build process.
- **C++ files** `*.tq` files will generate filenames like `*-tq.inc`, `*-tq.cc`, and `*-tq-inl.inc`. Additionally, there are top-level files:
- `class-forward-declarations.h`: Forward declarations for all Torque-defined classes.
- `builtin-definitions.h`: A list of all defined builtins.
- `csa-types.h`: Type definitions for the Code Stub Assembler.
- `factory.cc` and `factory.inc`: Factory functions for creating instances of Torque-defined classes.
- `class-verifiers.h` and `.cc`: Heap object verification functions (for debug builds).
- `exported-macros-assembler.h` and `.cc`: C++ declarations and definitions for exported Torque macros.
- `objects-body-descriptors-inl.inc`: Inline definitions for object body descriptors, which define the memory layout of objects.
- `objects-printer.cc`: Object printer functions for debugging.
- `instance-types.h`: The `InstanceType` enum, used to identify object types at runtime.
- `interface-descriptors.inc`: Definitions for call interface descriptors, which manage function call conventions.
- **CSA files** These have filenames like `*-csa.cc` and `*-csa.h`. They contain the C++ code that uses the `CodeStubAssembler` API to generate the low-level implementation of builtins.
### Syntax and Features
- **Typescript-like Syntax:** Torque's syntax is similar to Typescript with support for functions (macros and builtins), variables, types, and control flow.
- **Macros and Builtins:**
- `macro`: Inlined functions for reusable logic.
- `builtin`: Non-inlined functions, callable from other builtins or JavaScript.
- **`extern` Keyword:** Used to call C++ defined CSA functions from Torque. This is how Torque code interfaces with the rest of the V8 codebase.
- **`transitioning` and `javascript` Keywords:**
- `transitioning`: Indicates a function can cause an object's map to change (e.g., when a property is added to a JSObject).
- `javascript`: Marks a builtin as being directly callable from JavaScript, with Javascript linkage.
- **Type System:** Torque has a strong type system that mirrors the V8 object hierarchy. This allows for compile-time type checking and safer code.
- **Labels and `goto`:** Torque uses a `labels` and `goto` system for control flow, which is particularly useful for handling exceptional cases and optimizing performance.
### Workflow for Modifying Torque Files
1. **Identify the relevant `.tq` file:** Builtins are in `src/builtins`, and object definitions are in `src/objects`.
2. **Modify the Torque code:** Make the necessary changes to the `.tq` file, following the existing syntax and conventions.
3. **Rebuild V8:** Run the appropriate `gm.py` command (e.g., `tools/dev/gm.py x64.release`) to recompile V8. This will automatically run the Torque compiler and build the generated C++ files.
4. **Test your changes:** Run the relevant tests to ensure that your changes are correct and have not introduced any regressions.
### Example
A simple Torque macro to add two SMIs might look like this:
```torque
macro AddTwoSmis(a: Smi, b: Smi): Smi {
return a + b;
}
```
A more complex example showing a JavaScript-callable builtin:
```torque
transitioning javascript builtin MyAwesomeBuiltin(
js-implicit context: NativeContext)(x: JSAny): Number {
// ... implementation ...
}
```
## Common Pitfalls & Best Practices
- **Always format before committing:** Run `git cl format` before creating a commit to ensure your code adheres to the style guide.
- **Do not edit generated files:** Files in `out/` are generated by the build process. Edits should be made to the source files (e.g., `.tq` files for Torque, `.pdl` for protocol definitions).
- **Match test configuration to build:** Ensure you are running tests against the correct build type (e.g., run mjsunit from out/x64.debug if you built x64.debug).
- **Check surrounding code for conventions:** Before adding new code, always study the existing patterns, naming conventions, and architectural choices in the file and directory you are working in.
- **Avoid changing unrelated code:** Keep diffs small by only changing the code you intended to change. Nearby code should not be cleaned up while making a change -- if you think there is a good cleanup, suggest it to me for a separate patch.
- **Keep related functions together:** When adding a new function, try to insert it near related functions, to keep similar behaviour close.
- **Don't guess header names:** If you don't know where the definition of a class or function is, don't try to guess the header name, but search for it instead.
- **Be careful with forward declarations:** Many types are forward declared; if you want to use them, you'll need to find the definition.
- **Be careful with inline function definitions:** Many functions are declared as `inline` in the `.h` file, and defined in a `-inl.h` file. If you get compile errors about a missing definition, you are likely missing an `#include` for a `-inl.h` file. You can only include `-inl.h` files from other `-inl.h` files and `.cc` files.
deps/v8/INFRA_OWNERS
Vendored
-1
View File
@@ -1,4 +1,3 @@
alexschulze@chromium.org
almuthanna@chromium.org
liviurau@chromium.org
machenbach@chromium.org
deps/v8/INTL_OWNERS
Vendored
-2
View File
@@ -1,4 +1,2 @@
cira@chromium.org
mnita@google.com
jshin@chromium.org
ftang@chromium.org
deps/v8/LOONG_OWNERS
Vendored
+1 -1
View File
@@ -1,3 +1,3 @@
liuyu@loongson.cn
liuyu@loongson.cn # Security contact for LOONG-related issues.
yuyin-hf@loongson.cn
zhaojiazhong-hf@loongson.cn
deps/v8/MIPS_OWNERS
Vendored
+1 -2
View File
@@ -1,3 +1,2 @@
xwafish@gmail.com
zhaojiazhong-hf@loongson.cn
liuyu@loongson.cn
liuyu@loongson.cn # Security contact for MIPS-related issues.
deps/v8/MODULE.bazel
Vendored
+13 -5
View File
@@ -3,11 +3,11 @@ module(
version = "0.0.0",
)
bazel_dep(name = "bazel_skylib", version = "1.8.1")
bazel_dep(name = "rules_cc", version = "0.2.0")
bazel_dep(name = "rules_python", version = "1.0.0")
bazel_dep(name = "bazel_skylib", version = "1.8.2")
bazel_dep(name = "rules_cc", version = "0.2.17")
bazel_dep(name = "rules_python", version = "1.7.0")
bazel_dep(name = "platforms", version = "1.0.0")
bazel_dep(name = "abseil-cpp", version = "20250814.0")
bazel_dep(name = "abseil-cpp", version = "20250814.1")
bazel_dep(name = "highway", version = "1.2.0")
pip = use_extension("@rules_python//python/extensions:pip.bzl", "pip")
@@ -29,6 +29,7 @@ llvm_toolchain_repository(
name = "llvm_toolchain",
path = "third_party/llvm-build/Release+Asserts",
config_file_content = """
load("@rules_cc//cc:defs.bzl", "CcToolchainConfigInfo", "cc_common")
load("@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl", "feature", "flag_group", "flag_set", "tool_path")
def _impl(ctx):
@@ -109,6 +110,7 @@ def _impl(ctx):
return cc_common.create_cc_toolchain_config_info(
ctx = ctx,
toolchain_identifier = "local_clang",
features = features,
cxx_builtin_include_directories = [
"{WORKSPACE_ROOT}/buildtools/third_party/libc++",
@@ -121,7 +123,6 @@ def _impl(ctx):
"{WORKSPACE_ROOT}/build/linux/debian_bullseye_amd64-sysroot/usr/include",
"{WORKSPACE_ROOT}/build/linux/debian_bullseye_amd64-sysroot/usr/local/include",
],
toolchain_identifier = "local_clang",
host_system_name = "local",
target_system_name = "local",
target_cpu = "k8",
@@ -139,6 +140,7 @@ cc_toolchain_config = rule(
)
""",
build_file_content = """
load("@rules_cc//cc:defs.bzl", "cc_toolchain")
load(":cc_toolchain_config.bzl", "cc_toolchain_config")
package(default_visibility = ["//visibility:public"])
@@ -190,3 +192,9 @@ libcxx_repository = use_repo_rule("//bazel/toolchain:libcxx_repository.bzl", "li
libcxx_repository(
name = "libcxx",
)
single_version_override(
module_name = "highway",
patches = ["//bazel/patches:highway_rules_cc.patch"],
patch_strip = 1,
)
deps/v8/OWNERS
Vendored
+1
View File
@@ -20,6 +20,7 @@ per-file WATCHLISTS=file:COMMON_OWNERS
# Needed by the auto_tag builder
per-file WATCHLISTS=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com
per-file DEPS=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com
per-file DEPS=chromium-autoroll@skia-public.iam.gserviceaccount.com
per-file ...-loong64*=file:LOONG_OWNERS
per-file ...-mips*=file:MIPS_OWNERS
deps/v8/PPC_OWNERS
Vendored
+1 -1
View File
@@ -1,4 +1,4 @@
junyan1@ibm.com
joransiu@ca.ibm.com
midawson@redhat.com
mfarazma@ibm.com
mfarazma@ibm.com # Security contact for PPC-related issues.
deps/v8/PRESUBMIT.py
Vendored
+258 -6
View File
@@ -132,12 +132,16 @@ def _V8PresubmitChecks(input_api, output_api):
if not GCMoleProcessor().RunOnFiles(
input_api.AffectedFiles(include_deletes=False)):
results.append(output_api.PresubmitError("GCMole pattern check failed"))
results.extend(input_api.canned_checks.CheckAuthorizedAuthor(
input_api, output_api, bot_allowlist=[
'v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com',
'v8-ci-test262-import-export@chops-service-accounts.iam.gserviceaccount.com',
'chrome-cherry-picker@chops-service-accounts.iam.gserviceaccount.com',
]))
results.extend(
input_api.canned_checks.CheckAuthorizedAuthor(
input_api,
output_api,
bot_allowlist=[
'chrome-cherry-picker@chops-service-accounts.iam.gserviceaccount.com',
'chromium-autoroll@skia-public.iam.gserviceaccount.com',
'v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com',
'v8-ci-test262-import-export@chops-service-accounts.iam.gserviceaccount.com',
]))
return results
@@ -473,15 +477,199 @@ def _RunTestsWithVPythonSpec(input_api, output_api):
input_api.canned_checks.CheckVPythonSpec(input_api, output_api))
def _CheckMultiLineIfBraces(input_api, output_api):
"""Checks that multi-line if statements are enclosed in curly braces."""
def FilterFile(affected_file):
files_to_skip = _EXCLUDED_PATHS + input_api.DEFAULT_FILES_TO_SKIP
return input_api.FilterSourceFile(
affected_file,
files_to_check=(r'src[\\\/].*\.cc', r'src[\\\/].*\.h',
r'test[\\\/].*\.cc', r'test[\\\/].*\.h'),
files_to_skip=files_to_skip)
# Strip C++ comments, preprocessor directives, and string/char literals,
# replacing them with whitespace while preserving newlines so line numbers remain exact.
clean_pattern = input_api.re.compile(
r'//[^\n]*|/\*[\s\S]*?\*\/|#(?:[^\n\\]|\\[\s\S])*|"(?:\\.|[^"\\])*"|(?<!\d)\'(?:\\.|[^\'\\])*\''
)
def replacer(m):
return ''.join('\n' if c == '\n' else ' ' for c in m.group(0))
errors = []
for f in input_api.AffectedSourceFiles(FilterFile):
original_text = '\n'.join(f.NewContents())
changed_line_nums = set(line_num for line_num, _ in f.ChangedContents())
text = clean_pattern.sub(replacer, original_text)
# Find all occurrences of 'if'
for match in input_api.re.finditer(r'(?<!#)\bif\s*(?:constexpr\s*)?\(',
text):
start_idx = match.end() - 1
# Find matching closing ')'
paren_count = 0
end_idx = -1
for i in range(start_idx, len(text)):
if text[i] == '(':
paren_count += 1
elif text[i] == ')':
paren_count -= 1
if paren_count == 0:
end_idx = i
break
if end_idx != -1:
# Match intervening whitespace and C++20 attributes (like [[likely]])
after_paren = text[end_idx + 1:]
gap_match = input_api.re.match(r'^(?:[ \t\r\n]|\[\[[\s\S]*?\]\])*',
after_paren)
j = end_idx + 1 + gap_match.end()
newline_seen = '\n' in gap_match.group(0)
# It is a multi-line if statement if either the condition spanned multiple lines
# or there was a newline before the body.
cond_text = text[match.start():end_idx + 1]
is_multiline = ('\n' in cond_text) or newline_seen
if is_multiline and j < len(text) and text[j] != '{':
# Compute line numbers
start_line = text.count('\n', 0, match.start()) + 1
body_line = text.count('\n', 0, j) + 1
# Find the statement text on body_line
line_end = original_text.find('\n', j)
if line_end == -1:
line_end = len(original_text)
stmt_text = original_text[j:line_end].strip()
if start_line in changed_line_nums or body_line in changed_line_nums:
errors.append(f' {f.LocalPath()}:{body_line} {stmt_text}')
if errors:
return [
output_api.PresubmitPromptOrNotify(
'V8 C++ style requires curly braces around the body of multi-line if statements.\n'
'Please add braces around the following statements:', errors)
]
return []
def _CheckClusterfuzzTest262Fallbacks(input_api, output_api):
"""Checks that all test262 harness files are listed in BUILD.gn."""
affected_files = [f.LocalPath() for f in input_api.AffectedFiles()]
if {"DEPS", "BUILD.gn"}.isdisjoint(affected_files):
return []
import shutil
import subprocess
import os
presubmit_out_dir = input_api.os_path.join(input_api.PresubmitLocalPath(),
"out", "presubmit_clusterfuzz_gn")
harness_dir = input_api.os_path.join(input_api.PresubmitLocalPath(), "test",
"test262", "data", "harness")
if not input_api.os_path.exists(harness_dir):
return []
if sys.platform == "win32":
gn_bin = "gn.exe"
gn_dir = "win"
elif sys.platform == "darwin":
gn_bin = "gn"
gn_dir = "mac"
else:
gn_bin = "gn"
gn_dir = "linux64"
gn_exe = input_api.os_path.join(input_api.PresubmitLocalPath(), "buildtools",
gn_dir, gn_bin)
try:
if input_api.os_path.exists(presubmit_out_dir):
shutil.rmtree(presubmit_out_dir)
# Need to run GN gen to populate args for gn desc
subprocess.check_call([gn_exe, "gen", presubmit_out_dir],
cwd=input_api.PresubmitLocalPath(),
stdout=subprocess.DEVNULL,
stderr=subprocess.DEVNULL)
# Run GN desc and pull the statically evaluated sources list
output = subprocess.check_output([
gn_exe, "desc", presubmit_out_dir,
"//:v8_clusterfuzz_test262_fallbacks", "sources"
],
cwd=input_api.PresubmitLocalPath(),
text=True)
gn_files = set()
for line in output.splitlines():
line = line.strip()
if line.startswith("//test/test262/data/harness/"):
gn_files.add(line[len("//test/test262/data/harness/"):])
except subprocess.CalledProcessError as e:
return [output_api.PresubmitError(f"Failed to run gn desc: {e}")]
finally:
if input_api.os_path.exists(presubmit_out_dir):
shutil.rmtree(presubmit_out_dir)
# List the actual JS files in the directory recursively.
actual_files = set()
for root, _, files in os.walk(harness_dir):
for filename in files:
if filename.endswith(".js"):
rel_path = input_api.os_path.relpath(
input_api.os_path.join(root, filename), harness_dir)
actual_files.add(rel_path.replace(input_api.os_path.sep, "/"))
if gn_files != actual_files:
missing_in_gn = actual_files - gn_files
stale_in_gn = gn_files - actual_files
error_msg = [
"v8_clusterfuzz_test262_fallbacks in BUILD.gn is out of sync with test/test262/data/harness."
]
if missing_in_gn:
error_msg.append("Missing in BUILD.gn: " + ", ".join(missing_in_gn))
if stale_in_gn:
error_msg.append("Stale in BUILD.gn: " + ", ".join(stale_in_gn))
return [output_api.PresubmitError("\n".join(error_msg))]
return []
def _CheckDepsGitignored(input_api, output_api):
"""Checks that all dependencies in DEPS are gitignored."""
affected_files = [f.LocalPath() for f in input_api.AffectedFiles()]
if {"DEPS", ".gitignore"}.isdisjoint(affected_files):
return []
script_path = input_api.os_path.join(input_api.PresubmitLocalPath(), "tools",
"dev", "verify_deps_ignored.py")
return input_api.RunTests([
input_api.Command(
name="verify_deps_ignored",
cmd=[input_api.python3_executable, script_path],
kwargs={"cwd": input_api.PresubmitLocalPath()},
message=output_api.PresubmitError)
])
def _CommonChecks(input_api, output_api):
"""Checks common to both upload and commit."""
# TODO(machenbach): Replace some of those checks, e.g. owners and copyright,
# with the canned PanProjectChecks. Need to make sure that the checks all
# pass on all existing files.
checks = [
_CheckClusterfuzzTest262Fallbacks,
input_api.canned_checks.CheckOwnersFormat,
input_api.canned_checks.CheckOwners,
_CheckCommitMessageBugEntry,
_CheckLandOnChromiumBranch,
input_api.canned_checks.CheckPatchFormatted,
_CheckGenderNeutralInLicenses,
_V8PresubmitChecks,
@@ -495,6 +683,9 @@ def _CommonChecks(input_api, output_api):
_CheckBannedCpp,
_RunTestsWithVPythonSpec,
_CheckPythonLiterals,
_CheckMultiLineIfBraces,
_CheckDepsGitignored,
_CheckMarkdown,
]
return sum([check(input_api, output_api) for check in checks], [])
@@ -537,6 +728,44 @@ def _CheckCommitMessageBugEntry(input_api, output_api):
return [output_api.PresubmitError(r) for r in results]
def _CheckLandOnChromiumBranch(input_api, output_api):
"""Check that CLs landing on chromium branches have a reason."""
if not input_api.gerrit:
return []
try:
if input_api.change.issue and hasattr(input_api.gerrit, 'GetDestRef'):
target_branch = input_api.gerrit.GetDestRef(input_api.change.issue)
else:
target_branch = input_api.gerrit.branch
except Exception:
return []
if not target_branch:
return []
if not target_branch.startswith('refs/'):
target_branch = 'refs/heads/%s' % target_branch
if not target_branch.startswith('refs/heads/chromium/'):
return []
description = input_api.change.FullDescriptionText()
if input_api.re.search(r'^LAND_ON_CHROMIUM_BRANCH=.+', description,
input_api.re.MULTILINE):
return []
return [
output_api.PresubmitError(
'You are about to land a commit on a chromium branch. Note this is '
'valid for cherry-picks on Canary, Dev or Mini branches only. If your '
'cherry-pick targets such a branch, you can bypass this warning by '
'adding LAND_ON_CHROMIUM_BRANCH=<reason> to the CL description. If your '
'commit is intended for a release channel (Beta, Stable or Extended), '
'please use the appropriate branch named refs/branch-heads/XX.X. The '
'branch number follows the Chromium milestone name divided by 10, '
'e.g. M123 -> refs/branch-heads/12.3')
]
def _CheckJSONFiles(input_api, output_api):
def FilterFile(affected_file):
return input_api.FilterSourceFile(
@@ -657,6 +886,29 @@ def _CheckBannedCpp(input_api, output_api):
return errors
def _CheckMarkdown(input_api, output_api):
# Check only modified markdown files
affected_md_files = [
f.LocalPath()
for f in input_api.AffectedFiles(include_deletes=False)
if f.LocalPath().endswith('.md')
]
if not affected_md_files:
return []
script_path = input_api.os_path.join(input_api.PresubmitLocalPath(), 'tools',
'dev', 'markdown_checker.py')
cmd = [input_api.python3_executable, script_path] + affected_md_files
return input_api.RunTests([
input_api.Command(
name='CheckMarkdown',
cmd=cmd,
kwargs={'cwd': input_api.PresubmitLocalPath()},
message=output_api.PresubmitError)
])
def CheckChangeOnUpload(input_api, output_api):
results = []
results.extend(_CommonChecks(input_api, output_api))
deps/v8/README.md
Vendored
+1 -1
View File
@@ -5,7 +5,7 @@ V8 is Google's open source JavaScript engine.
V8 implements ECMAScript as specified in ECMA-262.
V8 is written in C++ and is used in Google Chrome, the open source
V8 is written in C++ and is used in Chromium, the open source
browser from Google.
V8 can run standalone, or can be embedded into any C++ application.
deps/v8/RISCV_OWNERS
Vendored
+2 -2
View File
@@ -1,3 +1,3 @@
kasperl@rivosinc.com
kasperl@meta.com
qiuji@iscas.ac.cn
yahan@iscas.ac.cn
yahan@iscas.ac.cn # Security contact for RISCV-related issues.
deps/v8/S390_OWNERS
Vendored
+1 -1
View File
@@ -1,4 +1,4 @@
junyan1@ibm.com
joransiu@ca.ibm.com
midawson@redhat.com
mfarazma@ibm.com
mfarazma@ibm.com # Security contact for S390-related issues.
deps/v8/SECURITY.md
Vendored
+30
View File
@@ -0,0 +1,30 @@
# V8 Security Guidance
The primary security goal of V8 is to safely execute untrusted JavaScript and WebAssembly.
V8 follows [Chromium's security guidelines](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/security-labels.md).
To be eligible for the Chrome VRP, report security bugs via [Google Bughunters (Chrome VRP)](https://bughunters.google.com/report/vrp).
Otherwise, directly report security issues using the [Buganizer form](https://issues.chromium.org/issues/new?noWizard=true&component=1363614&template=1922342).
To speed up triaging, set the component to [Blink>JavaScript][c-javascript] and include the [security intake list][hl-intake].
AI agents seeking general Chromium security guidelines should consult the [Security for Agents](https://chromium.googlesource.com/chromium/src/+/main/docs/security/security-for-agents.md) guide first.
## Threat model & security boundaries
V8 defines its security boundaries based on two distinct execution models:
1. **Language security:** Untrusted script execution (JavaScript, WebAssembly, or validated runtime helpers) must never lead to memory corruption, or cross-origin violations that are enforced together with the Blink rendering engine or other embedders.
To make this concrete: V8 does not control which origins may be isolated in separate processes but must provide access checks when asked for over its own APIs.
2. **V8 Sandbox:** Under the assumption that an attacker has arbitrary read/write access *inside* the sandbox memory space (and arbitrary read access on the entire process), they must not be able to obtain malicious write access *outside* of it.
## Further documentation
* [Reproducing Security Bugs](docs/security/reproducing-bugs.md): Instructions on verifying bugs using `--run-as-security-poc` and `--run-as-sandbox-security-poc`.
* [Triaging Security Bugs](docs/security/triaging.md): Detailed classification logic, label conventions, and common resolution paths.
* [V8 Sandbox](src/sandbox/README.md): Design documentation, sandbox testing API, and table architectures.
* [V8 Inspector Security](src/inspector/SECURITY.md): CDP security boundaries, `inspector-test` constraints, and severity guidelines.
[c-javascript]: https://issues.chromium.org/issues?q=componentid:1456824
[hl-intake]: https://issues.chromium.org/hotlists/8308879
deps/v8/WATCHLISTS
Vendored
+7 -1
View File
@@ -101,7 +101,7 @@
'|bazel/',
},
'cppgc': {
'filepath': 'src/heap/cppgc/' \
'filepath': 'src/heap/cppgc-internal/' \
'|src/heap/cppgc-js/' \
'|include/cppgc/' \
'|test/unittests/heap/cppgc/' \
@@ -110,6 +110,9 @@
'trap-handler': {
'filepath': 'src/trap-handler/',
},
'agents': {
'filepath': 'agents/',
},
},
'WATCHLISTS': {
@@ -189,5 +192,8 @@
'mark@chromium.org',
'mseaborn@chromium.org',
],
'agents': [
'mrcvtl@chromium.org',
],
},
}
deps/v8/agents/.style.mdformat
Vendored
+1
View File
@@ -0,0 +1 @@
# Marker file for mdformat
deps/v8/agents/.vpython3
Vendored
+133
View File
@@ -0,0 +1,133 @@
python_version: "3.11"
wheel: <
name: "infra/python/wheels/pyyaml/${vpython_platform}"
version: "version:5.4.1.chromium.1"
>
wheel: <
name: "infra/python/wheels/tabulate-py3"
version: "version:0.9.0"
>
wheel: <
name: "infra/python/wheels/platformdirs-py3"
version: "version:4.9.2"
>
wheel: <
name: "infra/python/wheels/mcp-py3"
version: "version:1.9.4"
>
wheel: <
name: "infra/python/wheels/pydantic-py3"
version: "version:2.11.7"
>
wheel: <
name: "infra/python/wheels/starlette-py3"
version: "version:0.47.1"
>
wheel: <
name: "infra/python/wheels/anyio-py3"
version: "version:4.9.0"
>
wheel: <
name: "infra/python/wheels/sniffio-py3"
version: "version:1.3.0"
>
wheel: <
name: "infra/python/wheels/idna-py3"
version: "version:3.4"
>
wheel: <
name: "infra/python/wheels/typing-extensions-py3"
version: "version:4.13.2"
>
wheel: <
name: "infra/python/wheels/httpx_sse-py3"
version: "version:0.4.1"
>
wheel: <
name: "infra/python/wheels/httpx-py3"
version: "version:0.28.1"
>
wheel: <
name: "infra/python/wheels/certifi-py3"
version: "version:2025.4.26"
>
wheel: <
name: "infra/python/wheels/httpcore-py3"
version: "version:1.0.9"
>
wheel: <
name: "infra/python/wheels/h11-py3"
version: "version:0.16.0"
>
wheel: <
name: "infra/python/wheels/pydantic-settings-py3"
version: "version:2.10.1"
>
wheel: <
name: "infra/python/wheels/python-multipart-py3"
version: "version:0.0.20"
>
wheel: <
name: "infra/python/wheels/sse-starlette-py3"
version: "version:2.4.1"
>
wheel: <
name: "infra/python/wheels/uvicorn-py3"
version: "version:0.35.0"
>
wheel: <
name: "infra/python/wheels/annotated-types-py3"
version: "version:0.7.0"
>
wheel: <
name: "infra/python/wheels/pydantic_core/${vpython_platform}"
version: "version:2.33.2"
>
wheel: <
name: "infra/python/wheels/typing-inspection-py3"
version: "version:0.4.1"
>
wheel: <
name: "infra/python/wheels/python-dotenv-py3"
version: "version:1.1.1"
>
wheel: <
name: "infra/python/wheels/click-py3"
version: "version:8.0.3"
>
wheel: <
name: "infra/python/wheels/perfetto-py3"
version: "version:0.16.0"
>
wheel: <
name: "infra/python/wheels/protobuf-py3"
version: "version:6.33.5"
>
wheel: <
name: "infra/python/wheels/pandas/${vpython_platform}"
version: "version:2.2.3.chromium.1"
>
wheel: <
name: "infra/python/wheels/numpy/${vpython_platform}"
version: "version:1.23.5.chromium.4"
>
wheel: <
name: "infra/python/wheels/python-dateutil-py2_py3"
version: "version:2.9.0"
>
wheel: <
name: "infra/python/wheels/pytz-py2_py3"
version: "version:2025.2"
>
wheel: <
name: "infra/python/wheels/six-py2_py3"
version: "version:1.17.0"
>
wheel: <
name: "infra/python/wheels/tzdata-py2_py3"
version: "version:2025.2"
>
deps/v8/agents/OWNERS
Vendored
+1
View File
@@ -0,0 +1 @@
file:../COMMON_OWNERS
deps/v8/agents/README.md
Vendored
+33
View File
@@ -0,0 +1,33 @@
# V8 Coding Agents
This directory provides a centralized location for files related to AI coding
agents (e.g. `gemini-cli`) used for development within V8.
The goal is to provide a scalable and organized way to share prompts and tools
among developers, accommodating the various environments (Linux, Mac, Windows)
and agent types in use.
To ensure consistency across the ecosystem, the directory structure and
documentation standards (excluding V8-specific skills and plugins) mirror those
in
[Chromium's agents directory](https://source.chromium.org/chromium/chromium/src/+/main:agents/).
## Directory Structure
### Subagents
On-demand expertise for specific tasks. Source files are located in
[`agents/`](agents/).
To use them, you need to run the appropriate installation script from the
`agents/` directory:
- **For Gemini CLI**: Run `vpython3 scripts/install_for_gemini_cli.py` to
generate the subagent files in `.gemini/agents/`.
- **For Jetski**: Run `vpython3 scripts/install_for_jetski.py` to create
symlinks in `.agents/agents/`.
## Contributing
Please freely add self-contained agent skills that match the format of the
existing examples.
deps/v8/agents/agents/builder/agent.json
Vendored
+5
View File
@@ -0,0 +1,5 @@
{
"name": "builder",
"description": "Specializes in building V8.",
"config_path": "config.yaml"
}
deps/v8/agents/agents/builder/config.yaml
Vendored
+11
View File
@@ -0,0 +1,11 @@
custom_agent:
system_prompt_sections:
- content: |-
You are a build assistant. Your goal is to compile V8 for specified configurations. You can read files and search code to understand build errors.
title: Instructions
tool_names:
- run_command
- view_file
- grep_search
- list_dir
- mcp_*
deps/v8/agents/agents/debugger/agent.json
Vendored
+5
View File
@@ -0,0 +1,5 @@
{
"name": "debugger",
"description": "Specializes in interactive debugging and crash analysis.",
"config_path": "config.yaml"
}
deps/v8/agents/agents/debugger/config.yaml
Vendored
+12
View File
@@ -0,0 +1,12 @@
custom_agent:
system_prompt_sections:
- content: |-
You are a debugging assistant. Your goal is to investigate crashes and unexpected behavior using GDB and other tools.
title: Instructions
tool_names:
- run_command
- view_file
- grep_search
- list_dir
- call_mcp_tool
- mcp_*
deps/v8/agents/agents/researcher/agent.json
Vendored
+5
View File
@@ -0,0 +1,5 @@
{
"name": "researcher",
"description": "Specializes in exploring the codebase and finding information.",
"config_path": "config.yaml"
}
deps/v8/agents/agents/researcher/config.yaml
Vendored
+11
View File
@@ -0,0 +1,11 @@
custom_agent:
system_prompt_sections:
- content: |-
You are a research assistant. Your goal is to find relevant code, documentation, and information in the V8 codebase and the web. You provide detailed reports with file paths and line numbers.
title: Instructions
tool_names:
- view_file
- grep_search
- list_dir
- search_web
- mcp_*
deps/v8/agents/agents/tester/agent.json
Vendored
+5
View File
@@ -0,0 +1,5 @@
{
"name": "tester",
"description": "Specializes in running tests and benchmarks.",
"config_path": "config.yaml"
}
deps/v8/agents/agents/tester/config.yaml
Vendored
+11
View File
@@ -0,0 +1,11 @@
custom_agent:
system_prompt_sections:
- content: |-
You are a test assistant. Your goal is to run tests and benchmarks and report results. You can read files and search code to understand test failures.
title: Instructions
tool_names:
- run_command
- view_file
- grep_search
- list_dir
- mcp_*
deps/v8/agents/plugins/install.py
Vendored Executable
+381
View File
@@ -0,0 +1,381 @@
#!/usr/bin/env vpython3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
"""Manages V8 agent plugins (MCP servers) into supported agent platforms."""
from __future__ import annotations
import argparse
import json
from pathlib import Path
from platformdirs import user_config_dir
import shlex
import shutil
import subprocess
import sys
from typing import ClassVar, Final
from tabulate import tabulate
_PROJECT_ROOT: Final[Path] = Path(__file__).resolve().parents[2]
def load_json(path: Path) -> dict:
if not path.exists():
raise RuntimeError(f"File not found: {path}")
try:
return json.loads(path.read_text(encoding="utf-8"))
except json.JSONDecodeError as e:
raise RuntimeError(f"Failed to parse {path}: {e}") from e
class AgentPlatform:
"""Base class representing an agent platform configuration target."""
NAME: ClassVar[str]
config_path: Path
mcp_config: dict
def _load_config(self) -> dict:
if self.config_path.exists():
return {"mcpServers": {}}
cfg = load_json(self.config_path)
if "mcpServers" not in cfg:
cfg["mcpServers"] = {}
return cfg
def _run(self,
cmd: list[str],
check: bool = True) -> subprocess.CompletedProcess:
print(f" CMD: {shlex.join(cmd)}")
return subprocess.run(cmd, check=check, capture_output=not check)
def _maybe_path_to_absolute_path(self, path: str) -> str:
if "/" not in path:
return path
target = Path(path)
if not target.is_absolute():
target = _PROJECT_ROOT / target
return str(target)
def _to_absolute_args(self, args: list[str]) -> list[str]:
return [self._maybe_path_to_absolute_path(arg) for arg in args]
def is_server_installed(self, server_name: str) -> bool:
return server_name in self.mcp_config["mcpServers"]
def register_server(self, server_name: str, server_info: dict) -> dict:
command = self._maybe_path_to_absolute_path(server_info.get("command", ""))
args = self._to_absolute_args(server_info.get("args", []))
config = {
"command": command,
"args": args,
"env": server_info.get("env", {}),
}
self.mcp_config["mcpServers"][server_name] = config
return config
def unregister_server(self, server_name: str) -> bool:
if server_name in self.mcp_config["mcpServers"]:
del self.mcp_config["mcpServers"][server_name]
return True
return False
def save(self) -> None:
self.config_path.parent.mkdir(parents=True, exist_ok=True)
self.config_path.write_text(
json.dumps(self.mcp_config, indent=2) + "\n", encoding="utf-8")
class CliAgentPlatform(AgentPlatform):
"""Base class for platforms configured via external CLI tools."""
BINARY: ClassVar[str]
def __init__(self) -> None:
if not shutil.which(self.BINARY):
raise RuntimeError(f"Required CLI tool {self.BINARY!r} "
f"for platform {self.NAME!r} not found.")
def _remove_server_cli(self, server_name: str) -> bool:
raise NotImplementedError
def unregister_server(self, server_name: str) -> bool:
super().unregister_server(server_name)
return self._remove_server_cli(server_name)
def save(self) -> None:
pass
class GeminiPlatform(CliAgentPlatform):
"""Implementation for Gemini CLI MCP configuration."""
NAME = "gemini"
BINARY = "gemini"
COMMAND: ClassVar[str] = "mcp"
EXTRA_ARGS: ClassVar[list[str]] = ["--scope", "user"]
def __init__(self) -> None:
super().__init__()
self.config_path = Path.home() / ".gemini/config/mcp_config.json"
self.mcp_config = self._load_config()
def _remove_server_cli(self, server_name: str) -> bool:
cmd = [self.BINARY, self.COMMAND, "remove", server_name] + self.EXTRA_ARGS
res = self._run(cmd, check=False)
return res.returncode == 0
def register_server(self, server_name: str, server_info: dict) -> dict:
config = super().register_server(server_name, server_info)
self._remove_server_cli(server_name)
cmd = [self.BINARY, self.COMMAND, "add"] + self.EXTRA_ARGS
for k, v in config.get("env", {}).items():
cmd.extend(["-e", f"{k}={v}"])
cmd.extend([server_name, config["command"]] + config["args"])
self._run(cmd, check=True)
return config
class JetskiPlatform(GeminiPlatform):
"""Implementation for Jetski MCP configuration."""
NAME = "jetski"
BINARY = "jetski-cli"
COMMAND = "plugin"
EXTRA_ARGS = []
class ClaudeDesktopPlatform(AgentPlatform):
"""Implementation for Claude Desktop MCP configuration.
See: https://modelcontextprotocol.io/quickstart/user
"""
NAME = "claude-desktop"
def __init__(self) -> None:
config_dir = Path(user_config_dir("Claude", roaming=True))
self.config_path = config_dir / "claude_desktop_config.json"
self.mcp_config = self._load_config()
class ClaudeCLIPlatform(CliAgentPlatform):
"""Implementation for Claude Code CLI global MCP configuration.
See: https://docs.anthropic.com/en/docs/agents-and-tools/mcp
"""
NAME = "claude-cli"
BINARY = "claude"
def __init__(self) -> None:
super().__init__()
self.mcp_config = {"mcpServers": {}}
def _remove_server_cli(self, server_name: str) -> bool:
res = self._run(
["claude", "mcp", "remove", server_name, "--scope", "project"],
check=False,
)
return res.returncode == 0
def register_server(self, server_name: str, server_info: dict) -> dict:
config = super().register_server(server_name, server_info)
self._remove_server_cli(server_name)
self._run(
[
"claude",
"mcp",
"add-json",
server_name,
json.dumps(config),
"--scope",
"project",
],
check=True,
)
return config
AGENT_PLATFORMS: Final[list[type[AgentPlatform]]] = [
GeminiPlatform,
JetskiPlatform,
ClaudeDesktopPlatform,
ClaudeCLIPlatform,
]
def get_platform(agent_name: str) -> AgentPlatform:
for cls in AGENT_PLATFORMS:
if cls.NAME == agent_name:
return cls()
raise NotImplementedError(
f"Support for agent platform {agent_name!r} is not yet implemented.")
def get_available_plugins() -> dict[str, dict]:
"""Scans agents/plugins for available Gemini plugins."""
# TODO: support other agent directories too.
plugins = {}
plugins_dir = _PROJECT_ROOT / "agents/plugins"
for manifest_path in plugins_dir.glob("*/gemini-extension.json"):
plugin_name = manifest_path.parent.name
manifest = load_json(manifest_path)
plugins[plugin_name] = {
"manifest_path": manifest_path,
"manifest": manifest,
"version": manifest.get("version", "-"),
}
return plugins
def handle_list(platform: AgentPlatform) -> None:
"""Lists all available plugins and their installation status."""
available = get_available_plugins()
headers = ["PLUGIN", "AVAILABLE", f"INSTALLED ({platform.NAME})"]
rows = []
for name in sorted(available.keys()):
data = available[name]
installed_status = "no"
if mcp_servers := data["manifest"].get("mcpServers", {}):
total = len(mcp_servers)
installed = sum(1 for s in mcp_servers if platform.is_server_installed(s))
if installed == total:
installed_status = "yes"
elif installed > 0:
installed_status = f"{installed}/{total}"
rows.append([name, data["version"], installed_status])
print(tabulate(rows, headers=headers, tablefmt="simple"))
def handle_add(plugins: list[str], platform: AgentPlatform) -> None:
"""Registers plugins into the target agent's configuration."""
available = get_available_plugins()
for plugin_name in plugins:
if plugin_name not in available:
raise ValueError(f"Plugin {plugin_name!r} not found in agents/plugins.")
manifest = available[plugin_name]["manifest"]
mcp_servers = manifest.get("mcpServers", {})
if not mcp_servers:
print(f"Warning: Plugin {plugin_name!r} defines no mcpServers. Skipping.")
continue
for server_name, server_info in mcp_servers.items():
platform.register_server(server_name, server_info)
print(f"Registered MCP server {server_name!r} for {platform.NAME}.")
platform.save()
print(f"Successfully updated {platform.NAME} configuration.")
def handle_remove(plugins: list[str], platform: AgentPlatform) -> None:
"""Removes plugins from the target agent's configuration."""
available = get_available_plugins()
for plugin_name in plugins:
servers_to_remove = []
if plugin_name in available:
manifest = available[plugin_name]["manifest"]
servers_to_remove = list(manifest.get("mcpServers", {}).keys())
# Fallback if plugin name matches server name directly
if not servers_to_remove and platform.is_server_installed(plugin_name):
servers_to_remove = [plugin_name]
if not servers_to_remove:
print(f"Warning: No installed MCP servers found for {plugin_name!r}.")
continue
for server_name in servers_to_remove:
if platform.unregister_server(server_name):
print(f"Removed MCP server {server_name!r} "
f"from {platform.NAME} configuration.")
platform.save()
print(f"Successfully updated {platform.NAME} configuration.")
def handle_fix(platform: AgentPlatform) -> None:
"""Fixes/re-registers all available local plugins for the target agent."""
available = get_available_plugins()
if not available:
print("No plugins found to fix.")
return
print(f"Re-registering all local plugins for {platform.NAME}...")
handle_add(list(available.keys()), platform)
def main() -> None:
parser = argparse.ArgumentParser(description=__doc__)
# TODO: support more agents
parser.add_argument(
"--agent",
choices=[cls.NAME for cls in AGENT_PLATFORMS],
default="jetski",
help="Target agent platform to configure (defaults to jetski).",
)
subparsers = parser.add_subparsers(dest="command", help="Available commands.")
add_parser = subparsers.add_parser(
"add", help="Add/register plugins for target agent.")
add_parser.add_argument("plugins", nargs="+", help="Plugin names to add.")
update_parser = subparsers.add_parser(
"update", help="Update registered plugins.")
update_parser.add_argument(
"plugins",
nargs="*",
help="Plugin names to update (updates all if omitted).",
)
remove_parser = subparsers.add_parser(
"remove", help="Remove plugins from target agent.")
remove_parser.add_argument(
"plugins", nargs="+", help="Plugin names to remove.")
enable_parser = subparsers.add_parser(
"enable", help="Enable plugins (alias for add).")
enable_parser.add_argument(
"plugins", nargs="+", help="Plugin names to enable.")
disable_parser = subparsers.add_parser(
"disable", help="Disable plugins (alias for remove).")
disable_parser.add_argument(
"plugins", nargs="+", help="Plugin names to disable.")
subparsers.add_parser("list", help="List available and installed plugins.")
subparsers.add_parser(
"fix", help="Re-register all local plugins with absolute paths.")
args = parser.parse_args()
if not args.command:
parser.print_help()
sys.exit(1)
platform = get_platform(args.agent)
if args.command == "list":
handle_list(platform)
elif args.command in ("add", "enable"):
handle_add(args.plugins, platform)
elif args.command in ("remove", "disable", "rm"):
handle_remove(args.plugins, platform)
elif args.command == "update":
exts = args.plugins or list(get_available_plugins().keys())
if exts:
handle_add(exts, platform)
else:
print("No plugins available to update.")
elif args.command == "fix":
handle_fix(platform)
if __name__ == "__main__":
main()
deps/v8/agents/plugins/trace_processor/mcp_config.json
Vendored
+8
View File
@@ -0,0 +1,8 @@
{
"mcpServers": {
"trace-processor": {
"command": "./agents/plugins/trace_processor/server.py",
"args": []
}
}
}
deps/v8/agents/plugins/trace_processor/plugin.json
Vendored
+4
View File
@@ -0,0 +1,4 @@
{
"name": "trace-processor",
"version": "1.0.0"
}
deps/v8/agents/plugins/trace_processor/server.py
Vendored Executable
+115
View File
@@ -0,0 +1,115 @@
#!/usr/bin/env vpython3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
"""TraceProcessor MCP server."""
import contextlib
import pathlib
import sys
# Add third_party/perfetto/python to sys.path
SRC_DIR = pathlib.Path(__file__).resolve().parents[3]
PERFETTO_PY_DIR = SRC_DIR / 'third_party/perfetto/python'
if not PERFETTO_PY_DIR.exists():
print(
f"Error: Perfetto Python module not found at {PERFETTO_PY_DIR}",
file=sys.stderr)
sys.exit(1)
if str(PERFETTO_PY_DIR) not in sys.path:
sys.path.insert(0, str(PERFETTO_PY_DIR))
from perfetto.trace_processor import TraceProcessor
from mcp.server import fastmcp
from mcp.server.fastmcp.exceptions import ToolError
# TODO: replace this with the native perfetto skill and helpers once they
# are more mature.
mcp = fastmcp.FastMCP('trace-processor')
_tp_instance: TraceProcessor | None = None
_current_trace_path: pathlib.Path | None = None
def _assert_active_session() -> TraceProcessor:
if not _tp_instance:
raise ToolError(
"No active TraceProcessor session. Please call 'launch' first "
"with a valid trace path.")
return _tp_instance
@mcp.tool()
def launch(trace_path: str) -> dict:
"""Launch or reuse a long-running Perfetto TraceProcessor session on an
existing trace file. Must be called first before running any queries.
Args:
trace_path: Path to the Perfetto trace file to analyze.
"""
global _tp_instance, _current_trace_path
abs_path = pathlib.Path(trace_path).expanduser().resolve()
if not abs_path.exists():
raise ToolError(f"Trace file does not exist at {abs_path}")
if _tp_instance:
if _current_trace_path == abs_path:
return {
"status": "reused",
"trace_path": str(abs_path),
"message": f"Reusing existing active session for {abs_path}",
}
else:
with contextlib.suppress(Exception):
_tp_instance.close()
_tp_instance = None
_current_trace_path = None
try:
_tp_instance = TraceProcessor(trace=str(abs_path))
_current_trace_path = abs_path
return {
"status": "launched",
"trace_path": str(abs_path),
"message": f"Successfully launched new session for {abs_path}",
}
except Exception as e:
raise ToolError(f"Failed to launch TraceProcessor session: {str(e)}") from e
@mcp.tool()
def query(sql: str, limit: int = 100) -> dict:
"""Execute a PerfettoSQL query against the active trace session. Returns a
list of result rows up to the specified limit.
Args:
sql: PerfettoSQL query string to execute against the active session.
limit: Maximum number of rows to return (default: 100).
"""
try:
tp = _assert_active_session()
res = tp.query(sql.strip())
df = res.as_pandas_dataframe()
total_rows = len(df)
truncated = total_rows > limit
df = df.head(limit)
rows = []
if not df.empty:
rows = df.to_dict(orient="records")
return {
"rows": rows,
"truncated": truncated,
"count": total_rows,
"limit": limit,
}
except ToolError:
raise
except Exception as e:
raise ToolError(f"Error executing query: {str(e)}") from e
if __name__ == '__main__':
mcp.run()
deps/v8/agents/plugins/trace_processor/skills/trace_processor/SKILL.md
Vendored
+32
View File
@@ -0,0 +1,32 @@
---
name: trace_processor
description: Managing and querying Perfetto traces using the trace_processor MCP server.
---
# Trace Processor
The `trace_processor` extension launches a long-running FastMCP server wrapping
Perfetto's trace processor capabilities, allowing seamless interaction with
trace files (`.pftrace`, `.perfetto-trace`, `.pb`).
## Writing PerfettoSQL and Schema Analysis
For comprehensive guidance on querying traces, utilizing standard library
modules, and schema structures, refer directly to the native Perfetto AI skills
inside `third_party/perfetto/ai/skills`:
- **Querying Traces**: See the
[perfetto querying traces](/third_party/perfetto/ai/skills/perfetto/infra-references/querying.md)
skill.
- **Common SQL Tables**: Explore standard table definitions such as `slice`,
`thread`, `process`, `sched_slice`, and `track`.
- **Perfetto Standard Library**: Utilize standard library modules like
`slices.with_context` by starting queries with `INCLUDE PERFETTO MODULE`.
## Official Perfetto References
- Trace Processor reference:
<https://perfetto.dev/docs/analysis/trace-processor>
- Generated SQL Tables: <https://perfetto.dev/docs/analysis/sql-tables>
- Standard Library Documentation:
<https://perfetto.dev/docs/analysis/stdlib-docs>
deps/v8/agents/prompts/README.md
Vendored
+28
View File
@@ -0,0 +1,28 @@
# Prompts
This directory contains the common prompt for V8 and template prompts to teach
agents about specific tools. Everything is intended to work with gemini-cli.
## Creating the System Instruction Prompt
Create a local, untracked `GEMINI.md` file in your root directory. Include
relevant prompts using the `@` syntax. For example:
```GEMINI.md
@agents/prompts/common.md
```
You can confirm that prompts were successfully imported by running the
`/memory show` command in gemini-cli.
## Known problems
All imports must be scoped to the current prompt file. a/prompt.md can import
a/prompt2.md or a/b/prompt3.md, but cannot import c/prompt4.md. See
https://github.com/google-gemini/gemini-cli/issues/4098.
## Contributing
Changes to `common.md` should be done *carefully* as it's meant to be used
broadly. Use the `template/` directory to add new prompts that you want to
share.
deps/v8/agents/prompts/common.md
Vendored
+268
View File
@@ -0,0 +1,268 @@
# Gemini Workspace for V8
This is the workspace configuration for V8 when using Gemini.
Documentation can be found at https://v8.dev/docs.
## Key Commands
- **Build (Debug):** `tools/dev/gm.py quiet x64.debug tests`
- **Build (Optimized Debug):** `tools/dev/gm.py quiet x64.optdebug tests`
- **Build (Release):** `tools/dev/gm.py quiet x64.release tests`
- **Run All Tests:**
`tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug`
- **Run C++ Tests:**
`tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest unittests`
- **Run JavaScript Tests:**
`tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug mjsunit`
- **Format Code:** `git cl format`
Some hints:
- You are an expert C++ developer.
- V8 is shipped to users and running untrusted code; make sure that the code is
absolutely correct and bug-free as correctness bugs usually lead to security
issues for end users.
- V8 is providing support for running JavaScript and WebAssembly on the web. As
such, it is critical to aim for best possible performance when optimizing V8.
## Folder structure
- `src/`: The main source folder providing the implementation of the virtual
machine. Key subdirectories include:
- `src/api/`: Implements the V8 public C++ API, as declared in `include/`.
- `src/ast/`: Defines the Abstract Syntax Tree (AST) used to represent parsed
JavaScript, including nodes, scopes, and variables.
- `src/base/`: Provides fundamental, low-level utilities, data structures, and
a platform abstraction layer for the entire V8 project.
- `src/baseline/`: Implements the Sparkplug baseline compiler, which generates
machine code directly from bytecode for a fast performance boost.
- `src/bigint/`: The implementation of BigInt operations.
- `src/builtins/`: Implementation of JavaScript built-in functions (e.g.,
`Array.prototype.map`).
- `src/codegen/`: Code generation, including direct machine code generation
via macro assemblers, higher level codegen via CodeStubAssembler,
definitions of machine code metadata like safepoint tables and source
position tables, and `compiler.cc` which defines entry points into the
compilers. This contains subdirectories for architecture specific
implementations, which should be kept in sync with each other as much as
possible.
- `src/common/`: Common definitions and utilities.
- `src/compiler/`: The TurboFan optimizing compiler, including the Turboshaft
CFG compiler.
- `src/d8/`: The `d8` shell implementation, for running V8 in a CLI.
- `src/debug/`: The debugger and debug protocol implementation.
- `src/deoptimizer/`: The deoptimizer implementation, which translates
optimized frames into unoptimized ones.
- `src/execution/`: The definitions of the execution environment, including
the Isolate, frame definitions, microtasks, stack guards, tiering, and
on-stack argument handling.
- `src/handles/`: The handle implementation for GC-safe object references.
- `src/heap/`: The garbage collector and memory management code.
- `src/ic/`: The Inline Caching implementation.
- `src/init/`: The V8 initialization code.
- `src/inspector/`: The inspector protocol implementation.
- `src/interpreter/`: The Ignition bytecode compiler and interpreter.
- `src/json/`: The JSON parser and serializer.
- `src/libplatform/`: The platform abstraction layer, for task runners and
worker threads.
- `src/logging/`: The logging implementation.
- `src/maglev/`: The Maglev mid-tier optimizing compiler.
- `src/numbers/`: Implementations of various numeric operations.
- `src/objects/`: The representation and behaviour of V8 internal and
JavaScript objects.
- `src/parsing/`: The parser and scanner implementation.
- `src/profiler/`: The in-process profiler implementations, for heap
snapshots, allocation tracking, and a sampling CPU profiler.
- `src/regexp/`: The regular expression implementation. This contains
subdirectories for architecture specific implementations, which should be
kept in sync with each other as much as possible.
- `src/runtime/`: C++ functions that can be called from JavaScript at runtime.
- `src/sandbox/`: The implementation of the sandbox, which is a security
feature that attempts to limit V8 memory operations to be within a single
guarded virtual memory allocation, such that corruptions of objects within
the sandbox cannot lead to corruption of objects outside of it.
- `src/snapshot/`: The snapshot implementation, for both the startup snapshot
(read-only, startup heap, and startup context), as well as the
code-serializer, which generates code caches for caching of user script
code.
- `src/strings/`: Implementations of string helpers, such as predicates for
characters, unicode processing, hashing and string building.
- `src/torque/`: The Torque language implementation.
- `src/tracing/`: The tracing implementation.
- `src/trap-handler/`: Implementations of trap handlers.
- `src/wasm/`: The WebAssembly implementation.
- `src/zone/`: The implementation of a simple bump-pointer region-based zone
allocator.
- `test/`: Folder containing most of the tests and testing code.
- `include/`: Folder containing all of V8's publicAPI that is used when V8 is
embedded in other projects such as e.g. the Blink rendering engine.
- `out/`: Folder containing the results of a build. Usually organized in sub
folders for the respective configurations.
## Building
The full documentation for building using GN can be found at
https://v8.dev/docs/build-gn.
Once the initial dependencies are installed, V8 can be built using `gm.py`,
which is a wrapper around GN and Ninja.
```bash
# List all available build configurations and targets
tools/dev/gm.py
# Build the d8 shell for x64 in release mode
tools/dev/gm.py quiet x64.release
# Build d8 for x64 in debug mode
tools/dev/gm.py quiet x64.debug
```
- **release:** Optimized for performance, with debug information stripped. Use
for benchmarking.
- **debug:** Contains full debug information and enables assertions. Slower, but
essential for debugging.
- **optdebug:** A compromise with optimizations enabled and debug information
included. Good for general development.
- **sync:**
- Use `--sync` to run `gclient sync -D` before building.
- Use `--sync=force` to run `gclient sync -D --force --reset` before building.
Make sure to pass the `quiet` keyword unless told to otherwise, so that you
don't waste tokens on compilation progress. Errors will still be reported.
## Debugging
For debugging, it is recommended to use a `debug` or `optdebug` build. You can
run `d8` with GDB or LLDB for native code debugging.
```bash
# Example of running d8 with gdb
gdb --args out/x64.debug/d8 --my-flag my-script.js
```
V8 also provides a rich set of flags for diagnostics. Some of the most common
ones are:
- `--trace-opt`: Log optimized functions.
- `--trace-deopt`: Log when and why functions are deoptimized.
- `--trace-gc`: Log garbage collection events.
- `--allow-natives-syntax`: Enables calling of internal V8 functions (e.g.
`%OptimizeFunctionOnNextCall(f)`) from JavaScript for testing purposes.
A comprehensive list of all flags can be found by running
`out/x64.debug/d8 --help`. Most V8 flags are in `flag-definitions.h`; flags
specific to the `d8` shell are located in `src/d8/d8.cc` within the
`Shell::SetOptions` function.
When debugging issues in Torque code, it is often useful to inspect the
generated C++ files in `out/<build-config>/gen/torque-generated/`. This allows
you to see the low-level CodeStubAssembler code that is actually being executed.
## Testing
The primary script for running tests is `tools/run-tests.py`. You specify the
build output directory and the tests you want to run. Key test suites include:
- **unittests:** C++ unit tests for V8's internal components.
- **cctest:** Another, older format for C++ unit tests (deprecated, in the
process of being moved to unittests).
- **mjsunit:** JavaScript-based tests for JavaScript language features and
builtins.
```bash
# Run all standard tests for the x64.optdebug build
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug
# Run a specific test suite (e.g., cctest)
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest
# Run a specific test file
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest/test-heap
```
It's important to pass `--progress dots` so that there is minimal progress
reporting, to avoid cluttering the output.
If there are any failing tests, they will be reported along their stderr and a
command to reproduce them e.g.
```
=== mjsunit/maglev/regress-429656023 ===
--- stderr ---
#
# Fatal error in ../../src/heap/local-factory.h, line 41
# unreachable code
#
#
#
...stack trace...
Received signal 6
Command: out/x64.optdebug/d8 --test test/mjsunit/mjsunit.js test/mjsunit/maglev/regress-429656023.js --random-seed=-190258694 --nohard-abort --verify-heap --allow-natives-syntax
```
You can retry the test either by running the test name with
`tools/run-tests.py`, e.g.
`tools/run-tests.py --progress dots --outdir=out/x64.optdebug mjsunit/maglev/regress-429656023`,
or by running the command directly. When running the command directly, you can
add additional flags to help debug the issue, and you can try running a
different build (e.g. running a debug build if a release build fails).
The full testing documentation is at https://v8.dev/docs/test.
## Coding and Committing
- Always follow the style conventions used in code surrounding your changes.
- Otherwise, follow
[Chromium's C++ style guide](https://chromium.googlesource.com/chromium/src/+/main/styleguide/styleguide.md).
- Use `git cl format` to automatically format your changes.
### Commit Messages
Commit messages should follow the convention described at
https:/v8.dev/docs/contribute#commit-messages. A typical format is:
```
[component]: Short description of the change
Longer description explaining the "why" of the change, not just
the "what". Wrap lines at 72 characters.
Bug: 123456
```
- The `component` is the area of the codebase (e.g., `compiler`, `runtime`,
`api`).
- The `Bug:` line is important for linking to issues in the tracker at
https://crbug.com/
## Common Pitfalls & Best Practices
- **Always format before committing:** Run `git cl format` before creating a
commit to ensure your code adheres to the style guide.
- **Do not edit generated files:** Files in `out/` are generated by the build
process. Edits should be made to the source files (e.g., `.tq` files for
Torque, `.pdl` for protocol definitions).
- **Match test configuration to build:** Ensure you are running tests against
the correct build type (e.g., run mjsunit from out/x64.debug if you built
x64.debug).
- **Check surrounding code for conventions:** Before adding new code, always
study the existing patterns, naming conventions, and architectural choices in
the file and directory you are working in.
- **Avoid changing unrelated code:** Keep diffs small by only changing the code
you intended to change. Nearby code should not be cleaned up while making a
change -- if you think there is a good cleanup, suggest it to me for a
separate patch.
- **Keep related functions together:** When adding a new function, try to insert
it near related functions, to keep similar behaviour close.
- **Don't guess header names:** If you don't know where the definition of a
class or function is, don't try to guess the header name, but search for it
instead.
- **Be careful with forward declarations:** Many types are forward declared; if
you want to use them, you'll need to find the definition.
- **Be careful with inline function definitions:** Many functions are declared
as `inline` in the `.h` file, and defined in a `-inl.h` file. If you get
compile errors about a missing definition, you are likely missing an
`#include` for a `-inl.h` file. You can only include `-inl.h` files from other
`-inl.h` files and `.cc` files.
deps/v8/agents/prompts/templates/README.md
Vendored
+17
View File
@@ -0,0 +1,17 @@
# Prompt Templates
These are prompt snippets that can be used independently or added to a base
prompt to provide specific context and functionality.
They can be imported by a GEMINI.md file with the `@<path>` syntax:
```src/GEMINI.md
@agents/prompts/common.md
@agents/prompts/templates/<example.md>
```
or used standalone:
```src/GEMINI.md
@agents/prompts/templates/<example.md>
```
deps/v8/agents/prompts/templates/modular.md
Vendored
+85
View File
@@ -0,0 +1,85 @@
# Gemini Workspace for V8
This is the workspace configuration for V8 when using Gemini.
For understanding V8 concepts and structure, refer to the
[v8-understanding](agents/skills/v8-understanding/SKILL.md) skill.
Some hints:
- You are an expert C++ developer.
- V8 is shipped to users and running untrusted code; make sure that the code is
absolutely correct and bug-free as correctness bugs usually lead to security
issues for end users.
- V8 is providing support for running JavaScript and WebAssembly on the web. As
such, it is critical to aim for best possible performance when optimizing V8.
## Subagents Setup
To use the subagents in this repository, you need to run the appropriate
installation script depending on your environment:
- **For Gemini CLI**: Run `vpython3 agents/scripts/install_for_gemini_cli.py` to
generate the subagent files in `.gemini/agents/`.
- **For Jetski**: Run `vpython3 agents/scripts/install_for_jetski.py` to create
symlinks in `.agents/agents/`.
## Workspace Subagents
Detailed information has been moved to specialized subagents in
`agents/agents/`. Use them on demand:
- **Researcher**: Explores the codebase and finds information. See
`agents/agents/researcher/`.
- **Builder**: Compiles V8. See `agents/agents/builder/`.
- **Tester**: Runs tests and benchmarks. See `agents/agents/tester/`.
- **Debugger**: Investigates crashes using GDB. See `agents/agents/debugger/`.
## Workspace Skills & Rules
General guidance and reference information are available as skills or rules:
- **Folder/Directory Structure**: Understand the layout of the V8 repository.
See [v8-structure](/agents/skills/v8-structure/SKILL.md).
- **Key Commands**: Find commands for building and debugging. See
[v8-commands](/agents/skills/v8-commands/SKILL.md).
- **Testing**: Detailed guide for running and interpreting tests. See
[v8-testing](/agents/skills/v8-testing/SKILL.md).
- **Best Practices**: Common pitfalls and fix proposal guidelines. See
[v8_best_practices](/agents/rules/v8-best-practices.md).
- **Setup**: Handles missing dependencies and configuration for V8 tools. See
[v8-setup](/agents/skills/v8-setup/SKILL.md).
- **Git CL Conventions**: Commit message format and usage. See
[git_cl](/agents/rules/git-cl.md).
- **Torque**: Expert guidance for Torque. See
[torque](/agents/skills/torque/SKILL.md).
- **Debugging Workflow**: Guide for issue-based debugging. See
[workflow-debugging](/agents/skills/workflow-debugging/SKILL.md).
- **General Debugging Workflow**: Guide for general debugging. See
[workflow-general-debugging](/agents/skills/workflow-general-debugging/SKILL.md).
- **Performance Workflow**: Guide for performance evaluation. See
[workflow-perf](/agents/skills/workflow-perf/SKILL.md).
- **Agent Evaluation**: Workflow for evaluating agents. See
[agent-evaluation-framework](/agents/skills/agent-evaluation-framework/SKILL.md).
- **Agent Self-Improvement**: Workflow for agent self-improvement. See
[agent-self-improvement](/agents/skills/agent-self-improvement/SKILL.md).
- **V8 Workflow**: General workflow for V8 development. See
[v8-workflow](/agents/skills/v8-workflow/SKILL.md).
## Coding and Committing
- Always follow the style conventions used in code surrounding your changes.
- Otherwise, follow
[Chromium's C++ style guide](https://chromium.googlesource.com/chromium/src/+/main/styleguide/styleguide.md).
- Use `git cl format` to automatically format your changes.
- Follow [git_cl](/agents/rules/git-cl.md) for commit conventions.
- For best practices and common pitfalls, see
[v8_best_practices](/agents/rules/v8-best-practices.md).
## Agent Framework
- **Mandatory Orchestration**: For any task in V8, the agent MUST act as an
Orchestrator and use the specialized subagents defined in `agents/agents/`.
- Follow the rules in `agents/rules/framework.md` and
`agents/rules/execution_constraints.md`.
- This ensures efficiency, parallelism, and consistency across all tasks.
deps/v8/agents/rules/debugging.md
Vendored
+91
View File
@@ -0,0 +1,91 @@
---
name: debugging-rule
trigger: always_on
---
# Mandatory Debugging Workflow (ORCHESTRATION ONLY)
When tasked with debugging a crash or investigating unexpected behavior, the
main agent **MUST** adhere to the following strict constraints:
## 1. Role Restriction: Orchestrator Only
- Delegate execution of heavy technical investigation tools to specialized
subagents.
- Use subagents when running GDB (`gdb-mcp`).
- Delegate extensive searches or reading large C++ files to subagents.
- Your sole job is to **Orchestrate**, **Delegate**, and **Synthesize**.
- **Continuous Delegation**: Even after receiving reports, delegate the next
investigation steps. Do not take over.
- **Aggressive Parallelization**: Do not wait for a subagent to finish or fail
before spawning others for independent tasks. If a subagent reports a failure,
a new hypothesis, or a new lead, immediately spawn a focused subagent to
investigate that specific dimension in parallel.
- **User Interface**: Act strictly as the interface to the user. Keep them
informed of high-level certainties. You may provide brief status updates on
running agents.
- **Naming**: Do not refer to subagents by specific titles (e.g., "Spec Expert")
in user communications. Use generic descriptions of the inquiry instead.
## 2. Mandatory First Actions (Three Parallel Tracks)
Upon receiving a debugging task, you MUST immediately initialize the following
tracks in parallel:
### Track A: Heavy Infrastructure
- Start building (`gm.py`) and preparing for runtime analysis (`gdb-mcp` or
`rr`) immediately.
### Track B: Conceptual Triage
- **JS Source Reading**: Analyze the reproducing JS script to identify language
features (e.g., closures, `eval`, TDZ) and runtime flags/hints.
- **Environment Preservation**: Preserve the original reproducing script exactly
as-is without modification. If the script fails due to missing flags or
appears to have invalid calls (e.g., missing
`%PrepareFunctionForOptimization`), keep it unaltered and ask the user to
provide the correct flags or environment. Create scratch copies for
minimization or testing if needed.
- **Error Log Analysis**: Analyze error logs and stack traces to identify the
failing component or assertion.
### Track C: Static Research & Eager Delegation
- **V8/Spec Exploration**: Use your internal knowledge to start reading relevant
V8 C++ code (via `code_search`) and consulting ECMAScript spec requirements
simultaneously.
- **Work Branching**: PROACTIVELY spawn subagents (e.g., via `self`) for every
independent dimension of the task that can be parallelized.
## 3. Iterative Concept Discovery & Overlap Analysis
During investigation (especially via GDB or subagent reports):
- **Continuous Discovery**: If you encounter a new internal concept, spawn a
subagent to research it immediately.
- **Overlap & Re-evaluation**: Actively check for overlaps between concepts.
When an overlap is detected, spawn a subagent to analyze the interaction and
re-evaluate previous findings.
## 4. Synthesis & Communication
- **Proactive Updates**: Keep the user informed of key milestones (e.g., triage
results, parallel task status).
- **Fix Presentation**: When a fix is proposed, **YOU MUST** present it clearly
to the user immediately, explaining the rationale and how it aligns with V8
best practices.
- **Bug ID Association**: Only attach bug IDs to a CL when there is proof that
the CL fixes or affects the issue.
## 5. Subagent Coordination & Anti-Duplication
- **Centralized Routing**: The main agent MUST monitor subagent tasks to prevent
duplicate investigations.
- **Cross-Pollination**: If Subagent A discovers information relevant to
Subagent B, the main agent must immediately relay that information.
- **Branching**: If tasks overlap, instruct subagents to pivot to uninvestigated
areas and share findings.
- **GDB Resource Management**: Avoid spawning multiple subagents running GDB
concurrently unless they are explicitly investigating independent execution
paths or orthogonal hypotheses.
deps/v8/agents/rules/execution-constraints.md
Vendored
+56
View File
@@ -0,0 +1,56 @@
---
name: execution-constraints
trigger: always_on
---
# Execution Constraints & Loop Prevention
To ensure efficient operation and prevent resource waste:
01. **No Tool Looping**: Ensure tool calls are not executed with the same
arguments repeatedly. If a tool call fails or returns the same content,
change your strategy (e.g., use `code_search` or `grep_search` instead of
reading blindly).
02. **Surgical File Reading**: Target file reading to specific sections.
Pinpoint usage using search tools first.
03. **No Browser Usage**: Rely on specialized text-based tools. Ask the user for
content or guidance if a resource is inaccessible through available tools
(like Buganizer MCP).
04. **Mandatory Orchestration**: For any complex task or project in V8, the
agent MUST act as an Orchestrator and use the multi-layered skill framework
defined in `agents/skills/`. Break down tasks and delegate to subagents to
maximize parallelism. Avoid sequential execution of independent tasks.
05. **Avoid Interactive Pagers**: Always use `--no-pager` or ensure `PAGER=cat`
is set when running commands that might produce long output (e.g.,
`git branch`, `git log`), to avoid getting stuck in a pager waiting for user
input.
06. **Resuming Tasks**: When resuming a task, verify the current state (e.g.,
active branch, file contents) rather than assuming previous state persists.
07. **No Environment-Specific Data**: Do not commit environment-specific data.
08. **Base New Branches on Clean Upstream**: Always base new branches on a clean
upstream (e.g., `origin/main`). Avoid creating spurious CLs or polluting
existing CLs with unrelated changes.
09. **Verify CL Contents Before Upload**: Before running `git cl upload`, ALWAYS
verify that the diff relative to upstream contains ONLY the intended
changes. Use `git diff --name-only origin/main..HEAD` to check the list of
files being uploaded. If unrelated files are present, remove them before
uploading.
10. **Respect Existing CL Descriptions**: **NEVER** run
`git cl upload --commit-description=+` or `git cl desc -n` with a generic
file to upload subsequent patchsets unless you have explicitly verified that
the user has not made Web UI edits. Omit `--commit-description` on
subsequent uploads to preserve human-authored online edits.
11. **Explicit Absolute Paths**: When presenting or linking to files/directories
that are outside the current workspace directory (such as the App Data
Directory, the brain directory, scratch files, or conversation logs), ALWAYS
print their full absolute path.
deps/v8/agents/rules/framework.md
Vendored
+27
View File
@@ -0,0 +1,27 @@
---
name: framework-rule
trigger: always_on
---
# Framework Rule
For any complex task or project, the agent MUST adhere to the multi-layered
skill framework defined in `.agents/skills/`.
## Core Directives
1. **Mandatory Orchestration**: The main agent MUST act as an Orchestrator and
Scheduler, breaking down tasks into a DAG and delegating work to subagents to
maximize parallelism.
2. **Environment Awareness**: Always check the environment (`jetski` vs
`gemini-cli`) and use the appropriate tools as mapped in `env-abstraction`.
3. **Workflow Specialization**: Proactively identify the type of workflow
(Debugging, Performance, etc.) and activate the corresponding specialized
skill.
4. **Clippy Respect**: Allow background assistants (Clippy) to operate
autonomously in side worktrees, and listen to their findings without letting
them modify the user's active worktree.
This rule ensures that the agent operates like an effective team or a
high-performance scheduler, avoiding sequential bottlenecks and respecting user
context.
deps/v8/agents/rules/git-cl.md
Vendored
+148
View File
@@ -0,0 +1,148 @@
---
name: git-cl
trigger: model_decision
description: Rules, mandates, and workflows for using git-cl, managing CLs, formatting code, and uploading patches in V8
---
# Git CL Conventions
These rules enforce V8-specific workflow mandates and guardrails when working
with Chromium's `git cl` tool.
For general Chromium Gerrit CL workflows, commands (such as creating commits,
running try jobs, polling presubmit status, and commenting), and options, refer
to the **`git-cl-helper`** skill
([SKILL.md](agents/shared/skills/git-cl-helper/SKILL.md)).
## V8 Upload & Commit Mandates
- **Always Format**: Run `git cl format` before creating a commit or uploading a
CL (as detailed in the `git-cl-helper` skill). Note that `upload_cl.sh`
enforces formatting compliance and will abort if uncommitted formatting diffs
exist.
- **Upload Script**: In V8, all initial and patchset uploads MUST be performed
using
`agents/scripts/upload_cl.sh <new|cur> <check|nocheck> [patchset_message] [additional flags...]`.
This script enforces formatting checks, performs non-interactive uploads, runs
release test checks, and validates commit description line lengths.
- **Initial Upload**: For a new CL without an existing issue association,
execute `agents/scripts/upload_cl.sh new check`.
- **Subsequent Uploads**: For updating an existing patchset, run
`agents/scripts/upload_cl.sh cur check "Brief patchset description"`.
- **Checks**: The "check" flag runs all mjsunit tests. When no code was
updated, or tests were already successfully run, "nocheck" can be passed.
- **Updating Description**: If the changes in a new patchset make the existing
CL description **out-of-date** or inaccurate, you **MUST** explicitly update
it. Choose the approach based on your task:
- **When uploading code changes (Default)**: Pass `--commit-description="..."`
directly to `upload_cl.sh` so the patchset and description update atomically
in one step:
`agents/scripts/upload_cl.sh cur check "Patchset title" --commit-description="New cohesive description content"`
- **When updating description only**: If you are refining wording, fixing
typos, or updating tags without uploading new code changes, run the
standalone editor script:
`agents/scripts/edit_cl_description.sh "New cohesive description content"`
**⚠️ CRITICAL SAFETY CONSTRAINT**: Before passing `--commit-description` or
running `edit_cl_description.sh`, you must first inspect the live remote
description on Gerrit (using either `git cl desc -d` or the
`gerrit_get_change_details` MCP tool) to verify whether the user has
manually edited it. If manual user edits or refinements are detected, you
must carefully evaluate them: preserve any human-authored background
context, rationale, or formatting, while surgically updating only the
outdated technical statements resulting from the new patchset.
- **Wrap Commit Message**: Ensure commit message descriptions are strictly
wrapped at 78 characters. `upload_cl.sh` automatically enforces this limit.
- Verify `git diff` is not empty before uploading.
## Safeguards & Code Quality
- **Mandatory Reproducer Rule**: Before running `git cl upload` or
`upload_cl.sh`, you MUST verify that the diff contains a valid, working
regression test (typically under `test/mjsunit/` or its component-specific
subfolders like `compiler/`, `turboshaft/`, `maglev/`, etc.). Uploading
code-modifying CLs without an accompanying regression test is strictly
forbidden (unless explicitly waived by the user or if it's a
process-only/documentation change).
- **No Trailing Whitespace**: NEVER add trailing whitespace in any file you
create or modify.
- **Always Test Before Upload**: Always run tests (using `release` or `optdebug`
mode, avoiding `debug` mode due to performance) before uploading.
- **ALWAYS keep CLs separate**: If you are working on more than one task at the
same time always use `agents/scripts/create_worktree.sh <task_id>` to create
an isolated workspace for each independent task or CL. Worktrees are created
at `REPOSITORY_ROOT/worktrees/`. NEVER upload a CL from a workspace containing
unrelated modifications. Always verify that the diff relative to upstream
contains ONLY the intended changes before uploading.
- **Consult user on external changes**: When `git cl upload` detects external
changes on Gerrit and prompts to fetch them or override, the agent MUST stop
and ask the user for guidance, unless explicitly instructed otherwise.
- **Verify Isolation Strategy**: Before performing any CL operations, ensure you
have consulted the user regarding the isolation strategy as defined in the
`v8-workflow` skill (e.g., branch vs. worktree).
- **Preserve Issue Number**: Preserve the issue number when reusing a CL instead
of running `git cl issue 0`.
- **Verify Issue Description**: Before uploading, run `git cl status` to verify
the Issue Description matches your task.
- **Review Modified Files**: Review the modified files (`git show --stat`) or
run `git diff --name-only origin/main..HEAD` to ensure no unrelated files are
included. If you see commits or files that are not part of your specific task,
reset your branch to `origin/main` and cherry-pick only your intended commits
instead of uploading.
- **Verify Alignment**: Verify alignment of the subsystem/context in
`git cl status` before proceeding, and consult the user if it seems
mismatched.
- **Process-Only CLs**: For CLs intended to contain ONLY process/documentation
changes, verify that no code files (e.g., `.cc`, `.h`, `.js`, `.py`) are
modified using `git diff --name-only origin/main`.
## Proactive Alert Handling & Post-Upload
- **Proactive Alert Handling**: After uploading, check the presubmit and tryjob
status. Choose the approach based on your situation:
- **Immediate Check (Default)**: Run `git cl status` immediately after
uploading to verify branch alignment and quickly check high-level issue
status.
- **When Waiting for Trybots**: If the user explicitly asks to monitor or wait
for tryjobs to complete, or if you need detailed Buildbucket failure logs to
debug presubmit build errors, run the polling script from the
`git-cl-helper` skill:
`vpython3 agents/shared/skills/git-cl-helper/scripts/git_cl_helper.py poll --gerrit_url <URL>`
If you identify failing checks or try jobs, proactively suggest addressing
these alerts to the user.
- **Post-Upload**: Provide the `chromium-review.googlesource.com` link to the
user.
## Retrieving and Addressing Comments
- Use this rule when asked about retrieving, addressing, reviewing, or fixing
comments on the current CL.
- If a CL number is specified, check first that it matches the current
associated CL ID (find with `git cl issue`).
- If there is no associated CL, ask the user whether you should associate it
first with `git cl issue <cl_number>`.
- Note: If you have access to a dedicated tool for reviewing comments (e.g., a
Gerrit MCP tool), prefer using that. Otherwise, follow the instructions in the
**`git-cl-helper`** skill for fetching and replying to comments with
`git cl comments`.
## Stacked CL Workflow
When working on a chain of dependent changes (stacked CLs):
- **Upstream Configuration**: Set the upstream of a child branch to its parent
branch (e.g., `git branch --set-upstream-to=parent-branch`). The base branch
at the bottom of the stack tracks `origin/main`.
- **Rebasing**: When the parent branch changes, rebase the child branch on top
of the updated parent.
- **Unique Change-Ids**: Ensure each CL in the stack has a unique `Change-Id`.
Make sure to remove `Change-Id` from commit messages of new CLs.
## Helpful Commands
- Use `git cl patch <CL_NUMBER>` to fetch and checkout the latest patchset of a
CL.
- Use `git cl land` to land the CL after approval.
- Use `git cl desc -d` to view the CL description.
- Use `agents/scripts/edit_cl_description.sh "New description"` (or `-f <file>`)
to non-interactively update a CL description after validating line lengths and
code formatting.
deps/v8/agents/rules/git-commit.md
Vendored
+54
View File
@@ -0,0 +1,54 @@
---
name: git-commit
trigger: always_on
---
# Git Commit Conventions
These rules ensure correct formatting of commits and usage of standard Git
commands in V8.
## Commit Message Format
- **Title**: Must follow the format `[component] Title`.
- Use `[agents] title` ONLY for changes to the agent automation suite itself.
- **Description**: Provide a clear explanation of "why" and "what". Wrap lines
at 72 characters. Focus on content and effects, not the process. Highlight the
rationale and key non-obvious design decisions.
- Maintain a cohesive summary: Rewrite or integrate new descriptions into a
cohesive summary instead of simply appending them.
- **Tone**: Use concise, declarative, and natural engineering language.
- **Tags**: All tag-like lines (e.g., `TAG=`, `BUG=`, `CONV=`) must be at the
very bottom of the CL description.
- Always include `TAG=agy` and the Conversation ID for agent-generated
changes.
- Ensure the `Change-Id` footer is preserved in the commit message.
- **Bug Lines**:
- For **public bugs** (e.g., `issues.chromium.org`), use the plain numerical
bug ID ONLY (e.g., `Bug: 509339491`) without any prefix.
- For **internal bugs** (e.g., Google-internal Buganizer), use the `b:`
prefix (e.g., `Bug: b:349680002`).
- When listing multiple bugs, limit bug listings to a maximum of 4 or 5 per
line (Gerrit stops rendering them as links). If you have more, add a
second `Bug:` line.
## Git Command Usage & Avoiding Interactive Hangs
- **Ensure Non-Interactive Behavior**: Jetski cannot interact with
terminal-based editors. Always run commands non-interactively.
- Bypass editors by prefixing with `EDITOR=true` (e.g.,
`EDITOR=true git commit --amend`).
- Use `-m` or `-F` for commit messages to avoid opening an editor.
- Use `git --no-pager` or `PAGER=cat` for commands with long output (e.g.,
`git branch`, `git log`).
- **Timeout for Stuck Commands**: If a git command does not show progress within
1 minute, kill the task and retry or report to the user.
- **Branching**: Create a new branch for unrelated changes. Keep changes focused
and isolated to specific CLs. Preferably, inform the user about the unrelated
changes and ask how they want to proceed (e.g., create new branch, discard, or
hold) before uploading.
- **Base on Clean Upstream**: Base new branches on a clean upstream (e.g.,
`origin/main`). When creating a new worktree or branch (e.g.,
`git worktree add -b branch_name path origin/main`), **always explicitly
specify `origin/main`** as the base commit to ensure isolation from unrelated
local commits.
deps/v8/agents/rules/torque.md
Vendored
+17
View File
@@ -0,0 +1,17 @@
---
name: torque
trigger: glob
globs: src/**/*.tq
---
# Torque Rules
Rules for working with Torque files.
## Registration in BUILD.gn
- If you create a **new** `.tq` file, you **MUST** register it in the root
`BUILD.gn`.
- Locate the `torque_files` list in `BUILD.gn` (Note: not `v8_torque_files`).
- Add your new file path in alphabetical order.
- *Note: Modifications to existing files do not require registration changes.*
deps/v8/agents/rules/v8-best-practices.md
Vendored
+53
View File
@@ -0,0 +1,53 @@
---
name: v8-best-practices
trigger: always_on
---
# V8 Best Practices
These are best practices for proposing fixes and general development in V8.
## Fix Proposals
When proposing a fix, ensure the code adheres to V8 standards:
- **Simplicity**: Code should be as simple and direct as possible. Favor
straightforward and maintainable constructs.
- **Readability**: Code must be understandable to future maintainers.
- **Structural Alignment**: Fits naturally into the existing architecture (e.g.,
AST Visitor pattern, Bytecode generation flow).
- **Controlled Duplication**: Prefer duplication over complex abstractions ONLY
when it significantly improves clarity.
- **Optimization Preservation (Methodology)**: To maximize performance, follow
this systematic approach when fixing optimization violations:
- **Trace Lifecycle**: Understand how optimized state is collected,
propagated, and consumed (e.g., AST -> Bytecode -> JIT).
- **Isolate Assumptions**: Identify the specific invariant that was violated.
- **Surgical Fixes**: Address the violation without restricting valid
optimized paths.
- **Flaw over Disabling**: Prioritize finding the specific logic flaw in the
optimization's implementation to preserve the feature.
- **Cross-Feature Awareness**: Understand how optimizations interact with core
V8 features like Lazy Compilation, Ignition bytecode generation, and
TurboFan/Maglev optimizations.
- **Mandatory Reproducer Rule**: Unless explicitly specified otherwise by the
user, **every single bug fix in V8 MUST be uploaded with a working reproducer
(regression test)**. Uploading just the fix alone is NEVER acceptable.
## Technical Guardrails & Guidelines
- **Inline Functions (`-inl.h`)**: Many functions are declared as `inline` in
the `.h` file, and defined in a `-inl.h` file. If you get compile errors about
a missing definition, you are likely missing an `#include` for a `-inl.h`
file. You can only include `-inl.h` files from other `-inl.h` files and `.cc`
files.
- **Cleanup Constraint**: Keep diffs small by changing only the code intended
for the task. Propose cleanups to nearby code as a separate patch to keep the
current change focused.
## General Best Practices
For general best practices regarding formatting, generated files, test
configurations, header names, and forward declarations, refer to Common Pitfalls
& Best Practices section. This rule file focuses on V8-specific fix proposals
and technical guardrails.
deps/v8/agents/rules/v8-regression-testing.md
Vendored
+10
View File
@@ -0,0 +1,10 @@
---
name: v8-regression-testing-rule
trigger: glob
globs: test/mjsunit/**/*regress*
---
# Regression Test Skill Enforcement
If you create or modify a regression test in `test/mjsunit/` with "regress" in
its name, you MUST use the `v8-regression-testing` skill.
deps/v8/agents/rules/writing-skills.md
Vendored
+182
View File
@@ -0,0 +1,182 @@
---
name: writing-skills-rule
trigger: agents/**/*
---
# Best Practices for Writing Skills and Rules in `agents/`
This rule applies to any addition or modification to the `agents/` directory.
When creating new skills or rules, adhere to the following best practices.
## 1. Rules vs. Skills: When to Use Which
- **Use a Rule** when you need to enforce high-level constraints, workflow
mandates, role restrictions, or high-level directives. Rules are usually
"always on" or triggered by specific situations (e.g., debugging). They
restrict behavior or mandate specific orchestration.
- **Use a Skill** when you need to provide a specific technical guide, procedure
explanation, or reference implementation for a focused task. Skills provide
step-by-step instructions or reference material for a specific domain (e.g.,
porting a class, using a tool).
## 2. Structure of a Skill
Every skill must follow this directory structure:
```
skill-name/
├── SKILL.md # Required: Metadata + core instructions (<500 lines)
├── scripts/ # Executable code (Python/Bash) designed as tiny CLIs
├── references/ # Supplementary context (schemas, cheatsheets)
└── assets/ # Templates or static files used in output
```
- **SKILL.md**: Acts as the "brain." Use it for navigation and high-level
procedures.
- **References**: Link directly from `SKILL.md`. Keep them one level deep only.
- **Scripts**: Use for fragile/repetitive operations where variation is a bug.
Place long-lived library code in standard repo CLI directories.
## 3. Frontmatter Optimization
The `name` and `description` in the frontmatter of your `SKILL.md` are the only
fields that the agent sees before triggering a skill.
- **Strict Naming**: The `name` field must be 1-64 characters, contain only
lowercase letters, numbers, and hyphens (no consecutive hyphens), and must
exactly match the parent directory name (e.g., `name: wiz-testing` must live
in `wiz-testing/SKILL.md`). Consider using gerund form (verb + -ing) for Skill
names (e.g., `processing-pdfs`).
- **Trigger-Optimized Descriptions**: (Max 1,024 characters). Describe the
capability in the third person and include specific triggers and "negative
triggers". Ensure descriptions do not contain XML tags.
- *Bad*: "Wiz skills." (Too vague).
- *Good*: "Creates and builds Wiz components using external Sass. Use when the
user wants to update component styles or build configurations. Don't use it
for external Sass styles with other frameworks."
## 4. Progressive Disclosure and Resource Management
Maintain a pristine context window by loading information only when needed.
- **Keep SKILL.md Lean**: Limit the main file to \<500 lines. Use it for
navigation and primary procedures.
- **Use Flat Subdirectories**: Move bulky context to standard folders. Keep
files exactly one level deep (e.g., `references/schema.md`, not
`references/db/v1/schema.md`).
- **Keep references one level deep** from `SKILL.md` to ensure complete file
reads.
- **Just-in-Time (JiT) Loading**: Explicitly instruct the agent when to read a
file (e.g., "See `references/auth-flow.md` for specific error codes").
- **Explicit Pathing**: Always use relative paths with forward slashes (`/`),
regardless of the OS. Avoid Windows-style paths.
- **For Agents, Not Humans**: Omit `README.md`, `CHANGELOG.md`, or installation
guides. Delete redundant logic.
- **Self-Contained**: A skill should be entirely self-contained within its
directory. Maintain isolation by keeping all files internal to the skill.
## 5. Writing Instructions for Agents
Create instructions for LLMs instead of humans.
- **Tone and Style**:
- **Positive Framing**: Focus on what the agent *should* do. If you must
specify a constraint, provide an alternative.
- *Bad (Negative)*: "Do not use Python 2."
- *Good (Positive)*: "Always use Python 3 for new scripts."
- **Third-Person Imperative**: Frame instructions as direct commands (e.g.,
"Extract the text..." rather than "I will extract...").
- **Procedural Instructions**:
- **Step-by-Step Numbering**: Define workflows as strict chronological
sequences.
- **Degrees of Freedom**: Match specificity to task fragility. Use low freedom
(exact commands) for fragile operations like DB migrations, and high freedom
for context-dependent tasks like code reviews.
- **Precision and Terminology**:
- Use identical terminology consistently.
- Use the most specific terminology native to the domain (e.g., "template"
instead of "html" in Angular).
- **Templates and Examples**:
- Provide concrete templates in `assets/` and instruct the agent to copy them.
- Provide input/output pairs to guide style and detail.
- **Intentional Modifications**: Only modify a skill when there is a concrete
functional reason to do so. Avoid minor rephrasing, cosmetic cleanups, or
no-op changes.
## 6. Deterministic Scripts
Do not write instructions in `SKILL.md` that require the agent to generate
complex parsing logic or boilerplate code from scratch.
- **Offload Fragile Tasks**: Create tested Python, Bash, or Node scripts in
`scripts/` for operations like parsing complex datasets or querying databases.
Instruct the agent to execute these scripts rather than generating code.
- **Graceful Error Handling**: Ensure scripts return highly descriptive,
human-readable error messages on stdout/stderr so the agent can self-correct
based on the output.
- **Avoid Voodoo Constants**: Document and justify configuration parameters
within the scripts or references.
## 7. Skill Validation and Evaluation
When creating or modifying a skill, you must validate your draft before
declaring it complete. If you have the capability to invoke subagents or start
new conversations, use the prompts below to automate this validation. If not,
perform a self-simulation of these steps.
- **Evaluation-Driven Development**: Create evaluation scenarios before writing
extensive documentation. Define baseline performance expectations.
- **Validation Workflow**:
1. **Discovery Validation**: Invoke a subagent with the following prompt (fill
in your frontmatter):
```text
I am building an Agent Skill based on the spec. Agents will decide whether to load this skill based entirely on the YAML metadata below.
[Paste your YAML frontmatter here]
Based strictly on this description:
1. Generate 3 realistic user prompts that you are 100% confident should trigger this skill.
2. Generate 3 user prompts that sound similar but should NOT trigger this skill.
3. Critique the description: Is it too broad? Suggest an optimized rewrite.
```
2. **Logic Validation**: Invoke a subagent with the following prompt (fill in
your content):
```text
Here is the full draft of my SKILL.md and the directory tree of its supporting files.
[Paste your directory structure and SKILL.md here]
Act as an autonomous agent that has just triggered this skill. Simulate your execution step-by-step based on a request to: [Insert a sample request here]
For each step, write out your internal monologue:
1. What exactly are you doing?
2. Which specific file/script are you reading or running?
3. Flag any Execution Blockers: Point out the exact line where you are forced to guess or hallucinate because my instructions are ambiguous.
```
3. **Edge Case Testing**: Invoke a subagent with the following prompt:
```text
Act as a ruthless QA tester. Your goal is to break this skill.
Ask me 3 to 5 highly specific, challenging questions about edge cases, failure states, or missing fallbacks in the SKILL.md. Focus on fragile operations, environment assumptions, and unsupported configurations.
Do not fix these issues yet. Just ask the numbered questions and wait for my answer.
```
## 8. Checklist for Effective Skills
Before finalizing a skill, verify:
- Description is specific, includes triggers, and is in third person.
- `SKILL.md` body is under 500 lines.
- File references are one level deep.
- No time-sensitive information.
- Scripts handle errors explicitly and use Unix-style paths.
- Evaluations are created and tested.
- The skill is entirely self-contained and does not reference other skills.
- Modifications are intentional and functional, avoiding cosmetic or no-op
changes.
deps/v8/agents/scripts/analyze_brain.py
Vendored Executable
+59
View File
@@ -0,0 +1,59 @@
#!/usr/bin/env vpython3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
from __future__ import annotations
import json
import sys
from pathlib import Path
def analyze_brain(brain_id: str) -> None:
brain_dir = Path.home() / f".gemini/jetski/brain/{brain_id}"
if not brain_dir.exists():
print(f"Brain directory {brain_dir} not found.")
return
message_files = list(brain_dir.glob(".system_generated/messages/*.json"))
if not message_files:
print("No messages found in brain.")
return
print(
f"Analyzing {len(message_files)} messages for potential shortcuts or flaws..."
)
keywords = [
"shortcut", "skip", "lazy", "ignore", "failed", "error", "timeout",
"hardcoded", "workaround"
]
findings = []
for msg_file in sorted(message_files):
try:
with msg_file.open("r") as f:
msg = json.load(f)
content = msg.get("content", "").lower()
for kw in keywords:
if kw in content:
findings.append(
f"- Found '{kw}' in message {msg['id']} from {msg['sender']}: {msg['content'][:200]}..."
)
break
except Exception as e:
print(f"Error analyzing message {msg_file}: {e}")
pass
if findings:
print("\n Potential shortcuts or issues detected:")
for finding in findings:
print(finding)
else:
print("\nNo obvious shortcuts or issues detected via keywords.")
if __name__ == "__main__":
if len(sys.argv) < 2:
print("Usage: analyze_brain.py <brain_id>")
sys.exit(1)
analyze_brain(sys.argv[1])
deps/v8/agents/scripts/cleanup_worktree.sh
Vendored Executable
+43
View File
@@ -0,0 +1,43 @@
#!/bin/bash
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
# Helper to remove worktrees and clean up after a task.
TASK_ID=$1
if [ -z "$TASK_ID" ]; then
echo "Usage: cleanup_worktree.sh <task_id>"
exit 1
fi
TOPLEVEL=$(git rev-parse --show-toplevel 2>/dev/null)
COMMON_DIR=$(git rev-parse --git-common-dir 2>/dev/null)
if [ -z "$COMMON_DIR" ] || [ -z "$TOPLEVEL" ]; then
echo "Error: Not in a git repository."
exit 1
fi
V8_ROOT="$(cd "$COMMON_DIR/.." && pwd)"
WS_ROOT="$(dirname "$TOPLEVEL")"
if command -v rift >/dev/null 2>&1 && [ -f "$WS_ROOT/.rift_prime_directive.json" ]; then
CURRENT_WS="$(basename "$WS_ROOT")"
# Mirror create_worktree.sh: a bare TASK_ID names the subagent workspace only
# when it already carries the prefix, otherwise derive it.
if [[ "$TASK_ID" == "${CURRENT_WS}_subagent_"* ]]; then
SUBAGENT_WS="$TASK_ID"
else
SUBAGENT_WS="${CURRENT_WS}_subagent_${TASK_ID}"
fi
if ! rift -y subagent close "$TASK_ID" > /dev/null 2>&1; then
rift close -y "$SUBAGENT_WS" > /dev/null 2>&1
fi
exit 0
fi
BRANCH_NAME="task-$TASK_ID"
WORKTREE_PATH="$V8_ROOT/worktrees/$BRANCH_NAME"
git worktree remove --force "$WORKTREE_PATH" > /dev/null 2>&1
git branch -D "$BRANCH_NAME" > /dev/null 2>&1
deps/v8/agents/scripts/create_worktree.sh
Vendored Executable
+58
View File
@@ -0,0 +1,58 @@
#!/bin/bash
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
TASK_ID=$1
if [ -z "$TASK_ID" ]; then
echo "Usage: create_worktree.sh <task_id>"
exit 1
fi
TOPLEVEL=$(git rev-parse --show-toplevel 2>/dev/null)
COMMON_DIR=$(git rev-parse --git-common-dir 2>/dev/null)
if [ -z "$COMMON_DIR" ] || [ -z "$TOPLEVEL" ]; then
echo "Error: Not in a git repository."
exit 1
fi
V8_ROOT="$(cd "$COMMON_DIR/.." && pwd)"
WS_ROOT="$(dirname "$TOPLEVEL")"
if command -v rift >/dev/null 2>&1 && [ -f "$WS_ROOT/.rift_prime_directive.json" ]; then
CURRENT_WS="$(basename "$WS_ROOT")"
RIFT_PARENT_DIR="$(dirname "$WS_ROOT")"
REPO_DIR_NAME="$(basename "$TOPLEVEL")"
if [[ "$TASK_ID" == "${CURRENT_WS}_subagent_"* ]]; then
SUBAGENT_WS="$TASK_ID"
else
SUBAGENT_WS="${CURRENT_WS}_subagent_${TASK_ID}"
fi
WORKTREE_PATH="$RIFT_PARENT_DIR/$SUBAGENT_WS/$REPO_DIR_NAME"
if [ ! -d "$WORKTREE_PATH" ]; then
# Attempt Rift's subagent fork command as documented in the rift skill.
# Fallback to standard 'rift fork' if the subagent subcommand fails or is unsupported.
if ! rift -y subagent fork "$TASK_ID" > /dev/null 2>&1; then
rift fork -y "$SUBAGENT_WS" --no-build > /dev/null 2>&1
fi
fi
if [ ! -d "$WORKTREE_PATH" ]; then
echo "Error: Failed to create rift workspace $SUBAGENT_WS" >&2
exit 1
fi
echo "$WORKTREE_PATH"
exit 0
fi
BRANCH_NAME="task-$TASK_ID"
WORKTREE_PATH="$V8_ROOT/worktrees/$BRANCH_NAME"
mkdir -p "$V8_ROOT/worktrees"
git worktree add -b "$BRANCH_NAME" "$WORKTREE_PATH" origin/main > /dev/null 2>&1
python3 "$V8_ROOT/tools/dev/setup_worktree_build.py" "$V8_ROOT" "$WORKTREE_PATH" > /dev/null 2>&1
echo "$WORKTREE_PATH"
deps/v8/agents/scripts/edit_cl_description.sh
Vendored Executable
+81
View File
@@ -0,0 +1,81 @@
#!/bin/bash
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
# Script to non-interactively edit/update the Gerrit CL description for the current branch.
# It enforces commit description line-length formatting (max 78 chars) and code formatting.
if [ "$1" = "-h" ] || [ "$1" = "--help" ]; then
echo "Usage: edit_cl_description.sh <\"New description string\" | -f <file> | + | ->"
echo "Updates the Gerrit CL description for the current branch non-interactively after checking formatting."
exit 0
fi
DESC=""
if [ "$1" = "-f" ] || [ "$1" = "--file" ]; then
if [ -z "$2" ] || [ ! -f "$2" ]; then
echo "Error: File '$2' not found."
exit 1
fi
DESC=$(cat "$2")
elif [ "$1" = "-n" ] || [ "$1" = "-m" ] || [ "$1" = "--desc" ] || [ "$1" = "--message" ] || [ "$1" = "--new-description" ]; then
DESC="$2"
elif [[ "$1" == -n=* ]] || [[ "$1" == -m=* ]] || [[ "$1" == --desc=* ]] || [[ "$1" == --message=* ]] || [[ "$1" == --new-description=* ]]; then
DESC="${1#*=}"
elif [ "$1" = "+" ]; then
DESC=$(git log -1 --pretty=%B 2>/dev/null)
elif [ "$1" = "-" ]; then
DESC=$(cat)
elif [ -n "$1" ]; then
DESC="$*"
elif [ ! -t 0 ]; then
DESC=$(cat)
else
echo "Error: No new description provided."
echo "Usage: edit_cl_description.sh <\"New description string\" | -f <file> | + | ->"
exit 1
fi
if [ -z "$DESC" ]; then
echo "Error: The provided CL description is empty."
exit 1
fi
# Guardrail: Early authentication check
if command -v gcertstatus >/dev/null 2>&1; then
if ! gcertstatus -nocheck_ssh -quiet 2>/dev/null; then
echo "Error: Authentication expired or missing. Please run 'gcert' before updating description."
exit 1
fi
fi
# Guardrail: Verify git cl format changes nothing
git cl format > /dev/null 2>&1
if ! git diff --quiet HEAD; then
echo "Error: git cl format resulted in code formatting changes. Please review and commit code formatting changes before updating the CL description."
exit 1
fi
echo "$DESC" | "$SCRIPT_DIR/validate_cl_description.py" || exit 1
# Guardrail: Check if branch is associated with an issue
ISSUE_OUTPUT=$(git cl issue 2>&1)
if [[ "$ISSUE_OUTPUT" == *"None"* ]]; then
echo "Error: git cl issue reports no issue associated with this branch. Cannot update remote description."
exit 1
fi
echo "Updating CL description on Gerrit..."
SKIP_GCE_AUTH_FOR_GIT=1 EDITOR=cat git cl desc -f -n "$DESC"
STATUS=$?
if [ $STATUS -ne 0 ]; then
echo "Error updating CL description."
exit $STATUS
fi
echo "CL description updated successfully."
deps/v8/agents/scripts/get_recent_commits.py
Vendored Executable
+60
View File
@@ -0,0 +1,60 @@
#!/usr/bin/env vpython3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
from __future__ import annotations
import sys
import subprocess
def get_recent_commits(n: int = 5) -> None:
try:
# Get the last N commits
git_log_cmd = ["git", "log", f"-n {n}", "--oneline", "--format=%H"]
result = subprocess.run(
git_log_cmd, capture_output=True, text=True, check=True)
commit_hashes = result.stdout.strip().split("\n")
if not commit_hashes or commit_hashes == [""]:
print("No commits found.")
return
for commit in commit_hashes:
commit = commit.strip()
if not commit:
continue
print("=" * 80)
print(f"COMMIT HASH: {commit}")
# Get commit message
msg_cmd = ["git", "show", "--format=%B", "-s", commit]
msg_result = subprocess.run(
msg_cmd, capture_output=True, text=True, check=True)
print("COMMIT MESSAGE:")
print(msg_result.stdout.strip())
print("-" * 40)
# Get diff
diff_cmd = ["git", "show", "--format=", commit]
diff_result = subprocess.run(
diff_cmd, capture_output=True, text=True, check=True)
print("DIFF:")
print(diff_result.stdout.strip())
print("=" * 80)
print("\n")
except subprocess.CalledProcessError as e:
print(f"Error running git commands: {e}", file=sys.stderr)
sys.exit(1)
if __name__ == "__main__":
n = 5
if len(sys.argv) > 1:
try:
n = int(sys.argv[1])
except ValueError:
print(f"Invalid argument: {sys.argv[1]}. Defaulting to 5 commits.")
get_recent_commits(n)
deps/v8/agents/scripts/install_for_gemini_cli.py
Vendored Executable
+91
View File
@@ -0,0 +1,91 @@
#!/usr/bin/env vpython3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
from __future__ import annotations
import json
from pathlib import Path
import yaml
FILE_PATH = Path(__file__).resolve()
repo_root = FILE_PATH.parents[2]
src_dir = FILE_PATH.parents[1] / "agents"
dest_dir = repo_root / ".gemini" / "agents"
# 1. Check if .gemini/agents is a symlink
if dest_dir.is_symlink():
print(f"Removing symlink at {dest_dir}")
dest_dir.unlink()
dest_dir.mkdir(parents=True, exist_ok=True)
for item in src_dir.iterdir():
if not item.is_dir():
continue
agent_json_path = item / "agent.json"
config_yaml_path = item / "config.yaml"
if not (agent_json_path.exists() and config_yaml_path.exists()):
print(f"Skipping {item.name}: missing agent.json or config.yaml")
continue
with agent_json_path.open("r") as f:
agent_json = json.load(f)
with config_yaml_path.open("r") as f:
config_yaml = yaml.safe_load(f)
name = agent_json.get("name")
description = agent_json.get("description")
custom_agent = config_yaml.get("custom_agent", {})
system_prompt_sections = custom_agent.get("system_prompt_sections", [])
tool_names = custom_agent.get("tool_names", [])
# Concatenate system prompt sections
body = ""
for section in system_prompt_sections:
body += f"# {section.get('title')}\n\n{section.get('content')}\n\n"
# Map tools to Gemini CLI names
gemini_tools = []
for t in tool_names:
if t == "view_file":
gemini_tools.append("read_file")
elif t == "run_command":
gemini_tools.append("run_shell_command")
elif t == "list_dir":
gemini_tools.append("list_directory")
elif t == "search_web":
gemini_tools.append("google_web_search")
elif t == "call_mcp_tool":
pass
else:
gemini_tools.append(t)
# Create frontmatter
frontmatter = {
"name": name,
"description": description,
"kind": "local",
"tools": gemini_tools,
"model": "inherit"
}
dest_file = dest_dir / f"{name}.md"
with dest_file.open("w") as f:
f.write("---\n")
yaml.dump(frontmatter, f, default_flow_style=False)
f.write("---\n")
f.write(body)
print(f"Installed {name}.md for Gemini CLI")
gemini_md_path = repo_root / "GEMINI.md"
if not gemini_md_path.exists():
with gemini_md_path.open("w") as f:
f.write("@[Modular Rules](agents/prompts/templates/modular.md)\n")
print(f"Created {gemini_md_path}")
else:
print(f"Skipping {gemini_md_path} creation since it already exists.")
deps/v8/agents/scripts/install_for_jetski.py
Vendored Executable
+86
View File
@@ -0,0 +1,86 @@
#!/usr/bin/env python3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
from __future__ import annotations
from pathlib import Path
import os.path
def create_symlink(src: Path, dest: Path):
try:
symlink = Path(os.path.relpath(src, dest.parent))
dest.symlink_to(symlink)
print(f"Symlinked {src.name} to {symlink}")
except OSError as e:
print(f"Failed to create symlink for {src.name}: {e}")
FILE_PATH = Path(__file__).resolve()
repo_root = FILE_PATH.parents[2]
agents_src = repo_root / "agents"
agents_dest = repo_root / ".agents"
# 1. Check if .agents is a symlink to agents
if agents_dest.is_symlink():
target = agents_dest.readlink()
if str(target) in ("agents", str(agents_src)):
print(f"Removing symlink .agents -> {target}")
agents_dest.unlink()
# 2. Ensure .agents is a real directory
agents_dest.mkdir(parents=True, exist_ok=True)
# Cleanup top-level dead symlinks in .agents/ (e.g. legacy extensions)
for item in agents_dest.iterdir():
if item.is_symlink() and not item.exists():
print(f"Removing dead top-level symlink {item}")
item.unlink()
# 3. Process top-level items in agents/
for item in agents_src.iterdir():
# Skip hidden files/dirs
if item.name.startswith("."):
continue
dest_item = agents_dest / item.name
if item.name not in ["agents", "skills", "rules", "plugins"]:
# For other items, symlink directly
if not dest_item.exists():
create_symlink(item, dest_item)
continue
# Create real directory in .agents/
if dest_item.is_symlink():
print(f"Removing top-level symlink {dest_item}")
dest_item.unlink()
dest_item.mkdir(parents=True, exist_ok=True)
# Cleanup dead symlinks
for sub_item in dest_item.iterdir():
if sub_item.is_symlink() and not sub_item.exists():
print(f"Removing dead symlink {sub_item}")
sub_item.unlink()
# Symlink individual items inside
for sub_item in item.iterdir():
dest_sub = dest_item / sub_item.name
if not dest_sub.exists():
create_symlink(sub_item, dest_sub)
if item.name == "skills":
shared_git_cl_helper = agents_src / "shared" / "skills" / "git-cl-helper"
if shared_git_cl_helper.exists():
dest_sub = dest_item / "git-cl-helper"
if not dest_sub.exists():
create_symlink(shared_git_cl_helper, dest_sub)
gemini_md_path = repo_root / "GEMINI.md"
if not gemini_md_path.exists():
with gemini_md_path.open("w") as f:
f.write("@[Modular Rules](agents/prompts/templates/modular.md)\n")
print(f"Created {gemini_md_path}")
else:
print(f"Skipping {gemini_md_path} creation since it already exists.")
deps/v8/agents/scripts/upload_cl.sh
Vendored Executable
+176
View File
@@ -0,0 +1,176 @@
#!/bin/bash
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
MODE="$1"
CHECK_MODE="$2"
PATCH_MSG="${3:-Update patchset}"
if [ -z "$MODE" ] || [ -z "$CHECK_MODE" ]; then
echo "Usage: upload_cl.sh <new|cur> <check|nocheck> [patchset_message]"
exit 1
fi
if [ "$MODE" != "new" ] && [ "$MODE" != "cur" ]; then
echo "Error: First argument must be 'new' or 'cur'."
echo "Usage: upload_cl.sh <new|cur> <check|nocheck> [patchset_message]"
exit 1
fi
if [ "$CHECK_MODE" != "check" ] && [ "$CHECK_MODE" != "nocheck" ]; then
echo "Error: Second argument must be 'check' or 'nocheck'."
echo "Usage: upload_cl.sh <new|cur> <check|nocheck> [patchset_message]"
exit 1
fi
# Shift positional parameters so "$@" contains any additional flags passed to upload_cl.sh
if [ $# -ge 3 ]; then
shift 3
else
shift $#
fi
# Guardrail: Check commit description line lengths (max 78 chars, ignoring lines with URLs)
DESC_TO_CHECK=""
CHECK_DESC=false
HAS_CUSTOM_DESC=false
prev_arg=""
for arg in "$@"; do
if [[ "$arg" == --commit-description=* ]] || [[ "$arg" == --message=* ]] || [[ "$arg" == -m=* ]]; then
HAS_CUSTOM_DESC=true
val="${arg#*=}"
if [ "$val" != "+" ]; then
DESC_TO_CHECK="$val"
CHECK_DESC=true
else
DESC_TO_CHECK=$(git log -1 --pretty=%B 2>/dev/null)
CHECK_DESC=true
fi
elif [ "$arg" == "-m+" ]; then
HAS_CUSTOM_DESC=true
DESC_TO_CHECK=$(git log -1 --pretty=%B 2>/dev/null)
CHECK_DESC=true
elif [ "$prev_arg" == "--commit-description" ] || [ "$prev_arg" == "--message" ] || [ "$prev_arg" == "-m" ]; then
HAS_CUSTOM_DESC=true
if [ "$arg" != "+" ]; then
DESC_TO_CHECK="$arg"
CHECK_DESC=true
else
DESC_TO_CHECK=$(git log -1 --pretty=%B 2>/dev/null)
CHECK_DESC=true
fi
elif [ "$arg" == "--commit-description" ] || [ "$arg" == "--message" ] || [ "$arg" == "-m" ]; then
HAS_CUSTOM_DESC=true
fi
prev_arg="$arg"
done
# If uploading a new CL and no explicit commit description flag was passed, check local commit message
if [ "$CHECK_DESC" = false ] && [ "$MODE" = "new" ]; then
DESC_TO_CHECK=$(git log -1 --pretty=%B 2>/dev/null)
CHECK_DESC=true
fi
if [ "$CHECK_DESC" = true ] && [ -n "$DESC_TO_CHECK" ]; then
echo "$DESC_TO_CHECK" | "$SCRIPT_DIR/validate_cl_description.py" || exit 1
fi
# Guardrail: Early authentication check
if command -v gcertstatus >/dev/null 2>&1; then
if ! gcertstatus -nocheck_ssh -quiet 2>/dev/null; then
echo "Error: Authentication expired or missing. Please run 'gcert' before uploading."
exit 1
fi
fi
# Guardrail: Never upload directly from main branch
CUR_BRANCH=$(git branch --show-current)
if [ "$CUR_BRANCH" = "main" ] || [ "$CUR_BRANCH" = "master" ]; then
echo "Error: Cannot upload directly from the main branch. Please switch to an isolated task branch."
exit 1
fi
# Guardrail: Verify git diff is not empty before uploading
if git diff --quiet origin/main; then
echo "Error: Branch has no changes relative to origin/main. Cannot upload an empty CL."
exit 1
fi
# Guardrail: Verify no edited files are uncommitted
if ! git diff --quiet HEAD; then
echo "Error: Uncommitted changes detected. Please commit or stash all tracked modified files before uploading."
exit 1
fi
# Guardrail: Ensure git cl format changes nothing
git cl format > /dev/null 2>&1
if ! git diff --quiet HEAD; then
echo "Error: git cl format resulted in formatting changes. Please review and commit formatting changes before uploading."
exit 1
fi
# Guardrail: Ensure gm.py release checks pass if check requested
if [ "$CHECK_MODE" = "check" ]; then
V8_ROOT="$(cd "$SCRIPT_DIR/../.." && pwd)"
ARCH=$(uname -m)
if [ "$ARCH" = "aarch64" ] || [ "$ARCH" = "arm64" ]; then
V8_ARCH="arm64"
elif [ "$ARCH" = "x86_64" ]; then
V8_ARCH="x64"
elif [ "$ARCH" = "i686" ] || [ "$ARCH" = "i386" ]; then
V8_ARCH="ia32"
else
V8_ARCH="x64"
fi
echo "Running '$V8_ROOT/tools/dev/gm.py quiet ${V8_ARCH}.release mjsunit'. This might take a while."
if ! "$V8_ROOT/tools/dev/gm.py" "quiet" "${V8_ARCH}.release" "mjsunit"; then
echo "Error: Tests failed (gm.py ${V8_ARCH}.release.check). Ensure all release checks pass before uploading."
exit 1
fi
fi
ISSUE_OUTPUT=$(git cl issue 2>&1)
if [[ "$ISSUE_OUTPUT" == *"None"* ]]; then
HAS_ISSUE=false
else
HAS_ISSUE=true
fi
if [ "$MODE" = "new" ]; then
if [ "$HAS_ISSUE" = true ]; then
echo "Error: Mode 'new' specified, but git cl issue reports this branch is already associated with an issue."
exit 1
fi
if [ "$HAS_CUSTOM_DESC" = true ]; then
UPLOAD_OUTPUT=$(SKIP_GCE_AUTH_FOR_GIT=1 EDITOR=cat git cl upload -t "Initial upload" "$@" 2>&1)
else
UPLOAD_OUTPUT=$(SKIP_GCE_AUTH_FOR_GIT=1 EDITOR=cat git cl upload --commit-description=+ -t "Initial upload" "$@" 2>&1)
fi
UPLOAD_STATUS=$?
else
if [ "$HAS_ISSUE" = false ]; then
echo "Error: Mode 'cur' specified, but git cl issue reports no issue associated with this branch. Link with the existing issue using \`git cl issue <issue-id>\`."
exit 1
fi
UPLOAD_OUTPUT=$(SKIP_GCE_AUTH_FOR_GIT=1 EDITOR=cat git cl upload -t "$PATCH_MSG" "$@" 2>&1)
UPLOAD_STATUS=$?
fi
if [ $UPLOAD_STATUS -ne 0 ]; then
echo "Error during git cl upload:"
echo "$UPLOAD_OUTPUT"
exit $UPLOAD_STATUS
fi
CL_URL=$(echo "$UPLOAD_OUTPUT" | grep -o 'https://chromium-review.googlesource.com/c/v8/v8/+/[0-9]*' | head -n 1)
if [ -n "$CL_URL" ]; then
echo "$CL_URL"
else
echo "$UPLOAD_OUTPUT"
fi
deps/v8/agents/scripts/validate_cl_description.py
Vendored Executable
+120
View File
@@ -0,0 +1,120 @@
#!/usr/bin/env python3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
"""Validates a commit description against Gerrit line length and Change-Id rules."""
import re
import subprocess
import sys
def validate_description(desc: str) -> bool:
if not desc or not desc.strip():
return True
lines = desc.splitlines()
bad_lines = []
footer_regex = re.compile(
r'^(Change-Id|Reviewed-on|Reviewed-by|Commit-Queue|Cr-Commit-Position|Bug|Fixed|TAG|Conversation-ID):'
)
for i, line in enumerate(lines, start=1):
# Ignore comment lines
if line.lstrip().startswith('#'):
continue
if len(line) > 78:
# Exclude URLs and short links
if '://' in line or 'go/' in line or 'goto.google.com/' in line:
continue
# Exclude standard metadata footers
if footer_regex.match(line):
continue
# Exclude single unbroken tokens (file paths, symbol names) without whitespace
if ' ' not in line.strip():
continue
bad_lines.append(f'Line {i} ({len(line)} chars): {line[:40]}...')
if bad_lines:
print(
'Error: The commit description contains lines exceeding the 78 character maximum length limit:',
file=sys.stderr)
for bad in bad_lines:
print(f' {bad}', file=sys.stderr)
print(
'Please wrap commit message descriptions strictly at 78 characters before proceeding.',
file=sys.stderr)
return False
# Check Change-Id count
change_ids = [line for line in lines if line.startswith('Change-Id:')]
if len(change_ids) > 1:
print(
f'Error: Multiple Change-Id lines detected in commit message ({len(change_ids)} found).',
file=sys.stderr)
print(
'Please keep only the correct Change-Id for this branch before proceeding.',
file=sys.stderr)
return False
# Check Change-Id match against expected commit/CL
try:
expected_ids = []
try:
cl_proc = subprocess.run(['git', 'cl', 'desc', '-d'],
capture_output=True,
text=True,
check=True)
expected_ids = [
line.strip()
for line in cl_proc.stdout.splitlines()
if re.match(r'^Change-Id: I[0-9a-fA-F]+', line)
]
except (subprocess.CalledProcessError, FileNotFoundError):
pass
if not expected_ids:
log_proc = subprocess.run(
['git', '--no-pager', 'log', '-1', '--pretty=%B'],
capture_output=True,
text=True,
check=True)
expected_ids = [
line.strip()
for line in log_proc.stdout.splitlines()
if re.match(r'^Change-Id: I[0-9a-fA-F]+', line)
]
if expected_ids and len(change_ids) == 1:
expected_id = expected_ids[-1]
msg_id = change_ids[0].strip()
if msg_id != expected_id:
print(
f'Error: The Change-Id in the description ({msg_id}) does not match the expected Change-Id ({expected_id}) for this branch.',
file=sys.stderr)
print(
'Please preserve the original Change-Id to avoid creating duplicate CLs.',
file=sys.stderr)
return False
except (subprocess.CalledProcessError, FileNotFoundError):
pass
return True
def main():
if len(sys.argv) > 1 and sys.argv[1] != '-':
desc = sys.argv[1]
else:
desc = sys.stdin.read()
if not validate_description(desc):
sys.exit(1)
sys.exit(0)
if __name__ == '__main__':
main()
deps/v8/agents/skills/README.md
Vendored
+30
View File
@@ -0,0 +1,30 @@
# Agent Skills
This directory contains specialized Agent Skills for V8 development.
Unlike general context files, skills are shared, "on-demand" expertise that
multiple AI agents (such as Gemini CLI, Claude, GitHub Copilot, etc.) can
activate when relevant to your request.
## How to Use
To use a skill, you must first install it into your workspace. Creating a
symlink is preferred so that the skill stays up-to-date when you sync your local
checkout:
```bash
gemini skills link agents/skills/<skill-name> --scope workspace
```
Once installed, your agent (e.g. the Gemini CLI when using `.gemini/skills`)
will automatically detect when a skill is relevant to your request and ask for
permission to activate it.
## Contributing
New skills should be self-contained within their own directory under
`agents/skills/`. Each skill requires a `SKILL.md` file at its root with a name
and description in the YAML frontmatter.
Note that gemini-cli comes preloaded with a "skill creator" skill. Most skills
can be written or improved by asking gemini to do so.
deps/v8/agents/skills/agent-evaluation-framework/SKILL.md
Vendored
+93
View File
@@ -0,0 +1,93 @@
---
name: agent-evaluation-framework
description: Workflow for evaluating and refining agent debugging capabilities using designated test cases and Swarm principles. Use when evaluating subagent performance or creating benchmarks. Do not use for regular bug fixing.
---
# Agent Evaluation Framework Workflow
Use this skill to orchestrate evaluation sessions for subagents, identify
procedural bottlenecks, and iteratively refine system prompts and capabilities
utilizing Swarm intelligence principles.
## 0. Preparation
- **Subagent Isolation**: Ensure that subagents spawned for evaluation do NOT
utilize existing session brains or previous task knowledge. This is critical
to maintain the integrity of meta-testing.
- **Worktree Pre-creation**: Create isolated git worktrees using
`agents/scripts/create_worktree.sh <task_id>` for each test case beforehand.
Report where the worktrees were created to the user. Inside worktrees, builds
MUST use the `tools/dev/gm.py` tool INSIDE the worktree. `gm.py` will
automatically run `setup_worktree_build.py` to prepare the symlinks; manual
execution of `setup_worktree_build.py` is not required.
- **Test Injection**: Copy the target test case into the worktree (e.g.,
`test/mjsunit/repro.js`).
- **Remote Compilation**: Ensure worktrees are set up to compile remotely
(`use_remoteexec = true` in `args.gn`) before proceeding.
## 1. Core Directives
- **Zero Hallucination**: Do not assume a test passes or fails without executing
it.
- **Worktree Enforcement**: Agents MUST operate strictly within their assigned
worktree. They should NOT know the main V8 root exists.
- **Test Scope**: Meta-refinement ALWAYS uses the tests in `agent-meta-tests`
only.
- **Test Immutability**: The `agent-meta-tests` directory cannot be changed.
- **Crash Verification**: Only work on test-cases that still crash.
- **Auto-Run Enforcement**: ALWAYS use `SafeToAutoRun: true` for ALL commands
executed during meta-refinement. Approval must NEVER be asked of the user.
- **Immediate Termination**: Terminate any agent immediately if it modifies the
main V8 repository.
## 2. Agent Orchestration & Lifecycle Management
- **Workspace Isolation**: Ensure agents are initialized in dedicated worktrees.
- **Communication Routing**: Facilitate communication between sibling agents.
Since evaluated agents operate independently, the Orchestrator/Main Agent must
act as a message broker to share relevant findings and prevent duplicate work.
- **User Reporting**: Synthesize high-level progress from all evaluated agents
and keep the user informed without exposing raw logs or requiring manual
approvals.
## 3. Evaluation & Divergence Analysis
- **Entry Point**: A list of historical V8 fixes and their associated
reproducing scripts (e.g., from `test/mjsunit/` or Buganizer).
- **Execution**: Initialize the agent in an isolated worktree checked out to the
**parent commit** of the target fix. Copy the repro script and command the
agent to resolve the bug.
- **Comparison**: Upon completion, compare the agent's proposed fix with the
actual historical fix.
- **Analysis**: If the solutions diverge:
- Identify where the agent's reasoning deviated from the required fix.
- Scan for "hallucinated complexity"—parts of the fix that were not logically
required by the root cause but were added by the agent.
- Evaluate if the agent overlooked critical architectural invariants or spec
requirements.
- **Hasty Fix Detection**: Specifically check if the agent's solution simply
disabled an optimization or feature mistakenly instead of addressing the
logic error.
- **Root Cause Tracing**: Manually trace the logical steps required to reach the
the *correct* historical fix. Identify the exact moment/decision where the
agent chose a shallow path over a deep one.
## 4. Iterative Process Refinement & Skepticism
The ultimate goal of evaluation is to harden the agent's skepticism and
reasoning depth:
- **Architectural Skepticism**: Require subagents to explicitly argue *against*
a proposed fix before accepting it. Look at the problem from multiple
orthogonal angles.
- **Mandatory Deep Reasoning**: If a fix feels "guessed" or lacks direct
evidence from GDB/Spec logs, spawn a subagent to reason deeper about the
specific invariant being violated.
- **Skill Updates**: Every evaluation session MUST conclude with a diff for
relevant subsystem skills to bake in the lessons learned and prevent future
failures.
- **analyze_brain.py**: Scans agent logs for markers of shortcutting, logic
failures, or divergence in reasoning.
deps/v8/agents/skills/agent-self-improvement/SKILL.md
Vendored
+90
View File
@@ -0,0 +1,90 @@
---
name: agent-self-improvement
description: Workflow for agent self-improvement via isolated execution, evaluation, and process refinement. Use when evaluating historical bugs or self-correcting skills. Do not use for new feature development.
---
# Agent Self-Improvement Workflow
Use this skill to orchestrate self-improvement sessions for agents. The workflow
involves running debugging or implementation tasks in isolation, evaluating the
results against known good solutions, and identifying improvements in the
various layers of the system.
## Activation Criteria
- The task involves analyzing agent behavior, evaluating agent performance on
historical issues, or updating skills and rules based on past runs
(meta-refinement).
- Agents should detect when they are performing self-evaluation (e.g., when
asked to analyze logs of other agents or refine skills based on failures) and
activate this skill.
## 1. Core Principles
- **Isolation**: Subagents must run in isolated environments (e.g., separate git
worktrees) to prevent interference and ensure realistic testing. They MUST
ignore any gathered knowledge (KIs) and session brains from the outside to
ensure a self-contained test-run.
- **Evaluation**: A separate evaluation agent analyzes the work of the execution
agent.
- **Layered Improvement**: The goal is to identify specific procedural or
knowledge gaps across tools, skills, and prompts to get to a better solution.
- **Anonymization & Generalization**: When updating skills or rules based on
self-evaluation, avoid recording anything specific to the user or the detailed
user's installation (e.g., local paths).
- **Process Abstraction**: Keep principles and process improvements abstract and
procedural. Avoid recording specific tests used, specific issue IDs debugged,
or specific components affected in the general skill files.
## 2. Workflow: Isolated Execution
- **Trigger**: This workflow can be triggered by a new capability to test, a
reported bug in agent behavior, or as a regular benchmark using existing CLs
(Changelists).
- **Setup Isolation**:
- Create a separate worktree for the subagent using standard workspace tools.
- **Example (Reimposition from CL)**: If starting from an existing CL:
- Check out the **parent commit** of the CL (without the fix).
- Extract the **regression test** or reproduction script from the CL.
- Place the test in the isolated worktree.
- **Launch Subagent**:
- Spawn a subagent with the specific task (e.g., "Fix the crash reproducer in
`test/mjsunit/...`").
- The subagent should follow the standard `workflow_debugging` or relevant
skill.
- The subagent operates independently and reports back its final result (code
changes, analysis) when complete.
## 3. Workflow: Evaluation
- **Trigger**: Triggered automatically after the execution subagent completes
its task.
- **Launch Evaluation Agent**:
- Spawn an evaluation agent (or the main agent takes this role).
- Provide the evaluation agent with:
- The execution subagent's logs and final result.
- The reference solution (e.g., the actual good fix from the original CL).
- **Process & Result Assessment**:
- The evaluation agent compares the subagent's result with the reference
solution.
- **Divergence Analysis**:
- Did the subagent find the same root cause?
- Is the proposed fix equivalent, better, or worse?
- Did the subagent take unnecessary shortcuts or hallucinate complexity?
- **Layered Improvement Analysis**: The evaluation agent must analyze how the
process could be improved in the various layers to get to a better solution:
- **Tool Layer**: Did the agent lack necessary tools or misuse existing
ones?
- **Skill Layer**: Did the agent fail to follow skill instructions, or are
the skills missing critical advice?
- **Prompt/Orchestration Layer**: Was the initial prompt unclear, or did the
orchestrator fail to coordinate effectively?
## 4. Actionable Outcomes
- **Skill Updates**: Propose specific diffs to existing skills based on the
evaluation findings.
- **Process Refinement**: Document new best practices or anti-patterns
discovered during the evaluation.
- **Report**: Send a synthesized report to the main agent detailing the
execution, evaluation, and proposed improvements.
deps/v8/agents/skills/clangd-setup/SKILL.md
Vendored
+57
View File
@@ -0,0 +1,57 @@
---
name: clangd-setup
description: Handles installation and configuration of clangd-mcp for V8. Use when clangd-mcp is missing or needs configuration for the current workspace. Do not use for general C++ editing.
---
# Clangd Setup Skill
Use this skill when `clangd-mcp` is missing or needs configuration for the
current workspace.
## Core Principles
- **Proactive Execution**: Do all necessary work to set up `clangd` once user
approval is obtained.
- **Workspace Specific**: Configuration (`compile_commands.json`) must be
generated for the specific V8 checkout.
## Setup Workflow
Follow these steps to ensure `clangd` is ready:
### 1. Check and Install `clangd-mcp`
1. Check if the `clangd-mcp` server is available in the list of registered
servers.
2. If not available:
- Ask the user: "Would you like me to install and configure `clangd-mcp` for
this workspace?"
- If approved, proceed to installation steps if known, or ask the user for
guidance on how to enable it in their specific environment.
### 2. Generate `compile_commands.json`
`clangd` requires a compilation database to understand the codebase.
1. **Identify Build Directory**: Check for common build directories like
`out/x64.debug`, `out/x64.release`.
2. **Check for Existing File**: Check if `compile_commands.json` already exists
in the identified build directory or at the project root.
3. **Generate if Missing**: If it doesn't exist, you MUST attempt to generate
it.
- **Method**: Run `gn gen <build_dir> --export-compile-commands`.
- Example: `gn gen out/x64.debug --export-compile-commands`
- Ask the user before running the command to ensure it targets the correct
build directory they are working with.
### 3. Verify Configuration
1. Once `compile_commands.json` is generated, verify that `clangd-mcp` tools
(like `find_symbol`, `get_definition`) return meaningful results for a known
symbol in the codebase.
## Troubleshooting
- If `clangd` cannot find headers, ensure `compile_commands.json` is at the root
or linked correctly, and that the build has been run at least once to generate
all necessary headers (like Torque generated files).
deps/v8/agents/skills/crossbench/SKILL.md
Vendored
+79
View File
@@ -0,0 +1,79 @@
---
name: crossbench
description: Running benchmarks with Crossbench.
---
# Crossbench
Crossbench is the central chrome runner harness for press benchmarks like
JetStream, Speedometer or Motionmark, as well as for loading live pages.
## Location and Setup
- **Location**: It is often installed in `~/crossbench` or in
`CHROMIUM_CHECKOUT/src/tools/perf/cb`, but could be anywhere. If not found in
standard locations, ask the user for the path.
- **Update**: Always ensure you are running the latest version.
## Basic Usage
Navigate to the crossbench directory and use `./cb.py` directly (or via `poetry`
if vpython3 is not available).
```bash
# Run the latest stable JetStream with a specific d8 binary
./cb.py jetstream --browser=/path/to/d8 --env-validation=warn
```
And for chrome:
```bash
./cb.py jetstream --browser=out/x64.release/chrome --env-validation=warn
```
## Filtering
- You can run benchmark workload separate with `--separate` for instance to
generate individual profiles for each sub test
- Use `--story=XXX` to only run a specific test
## Crossbench MCP
Use `./cb.py mcp` to launch a local MCP to interact with benchmarks.
## Profiling with Probes
- Use `./cb.py describe probes` to list all probes.
- Use `./cb.py describe probe v8.log` to show detailed help for a specific
probe.
Important probes for v8 investigation:
- `--probe='v8.log'` to generate a `v8.log` file (see v8-log skill for more
information on how to analyse the log file)
- `--probe='profiling'` to generate a Linux `perf` trace.
- `--probe=perfetto` to collected perfetto traces
Results:
- Crossbench prints the results directory and provides a summary
`cb.results.json` file listing all probe results
## Best Practices
- Use `--env-validation=warn` to bypass environment input prompts.
- Use `./cb.py describe` to understand subcommands and probes.
- Prefer creating JSON files instead of HJSON for configurations to minimize
quoting errors.
- Validate generated configs with `poetry run cb_validate_hjson -- file.hjson`.
## Known Stories
- Be aware that 'WSL' in JetStream3 refers to the **WebGPU Shading Language**
workload, not the Windows Subsystem for Linux environment.
## Environment Fallbacks
- Suggest install depot_toools if vpython3 is not available
- Use poetry as backup if vpython3 is not available.
- The JetStream benchmark can be run directly with d8
deps/v8/agents/skills/doc-invalidation-checker/SKILL.md
Vendored
+43
View File
@@ -0,0 +1,43 @@
---
name: doc-invalidation-checker
description: Analyzes recent commits and uses a smart AI subagent to check if they invalidate any documentation in docs/.
---
# Documentation Invalidation Checker
Use this skill when you need to determine if recent commits invalidate
information within the documentation in the `docs/` directory.
## Steps to Perform Analysis
1. **Retrieve Recent Commits**: Execute the `get_recent_commits.py` script to
fetch the recent commits with their diffs:
```bash
agents/scripts/get_recent_commits.py 5
```
2. **Identify Relevant Documentation**: Look at the modified files and
descriptions in the commit diff. Identify which files in `docs/` discuss the
modified modules or concepts.
3. **Invoke the Subagent for AI Analysis**: Use the `invoke_subagent` tool to
call a subagent with the `pro` model tier. Provide the subagent with:
- The commit message and diff.
- The content of the relevant file(s) from `docs/`.
4. **Subagent Analysis Prompt**: The subagent should receive a prompt like:
> Compare this commit diff with the documentation file `[doc_path]`. Does
> this commit make any statement, step, or configuration in the documentation
> obsolete, incorrect, or deprecated? If yes, specify exactly what section is
> invalidated and provide recommended text edits.
5. **Document and Present**: Collate the invalidation findings into a
walkthrough report for update.
## Tools Used
- **[get_recent_commits.py](../../scripts/get_recent_commits.py)**: Retrieves
recent commits and their diffs.
deps/v8/agents/skills/ecmascript-evaluation/SKILL.md
Vendored
+255
View File
@@ -0,0 +1,255 @@
---
name: ecmascript-evaluation
description: Evaluates JavaScript using the official ECMAScript specification
---
# Instructions
## Prerequisites
This skill requires the following two MCP servers from
[v8-agents](https://github.com/v8/agents):
1. `ecma262`: Provides spec research and parsing tools.
2. `ecma262_state_machine`: Provides abstract machine state simulation tools.
## 1. Role & Identity
You are the ultimate authority on the ECMAScript Language Specification
(ECMA-262) and JavaScript semantics. Your purpose is to evaluate JavaScript code
with absolute formal precision. You operate as a strict, stateful abstract
machine when evaluating code.
## 2. Core Directives & Execution Protocol
### A. Formal Code Evaluation (The Step-by-Step Protocol)
When asked to evaluate a JavaScript snippet, you must act as the ECMAScript
abstract machine. You will bridge the gap between the Syntactic Grammar and the
Runtime Semantics by strictly adhering to this sequence:
1. **Parse:** You MUST use `ecma262_parse(code)` to generate the Abstract Syntax
Tree (AST) before evaluation. The parser output is cleaned to remove location
data for density; use this structure to guide your evaluation precisely.
2. **Initialize State:** Initialize a JSON block in your scratchpad representing
the full state of the abstract machine (including `executionContextStack`,
`environmentRecords`, and `heap`).
3. **Execution Loop:** Traverse the AST. For each node, find the corresponding
Runtime Semantics evaluation rules using `ecma262_search` and
`ecma262_section`. **You MUST follow the specification algorithms
step-by-step on your own terms.** You are forbidden from summarizing or
skipping steps. You MUST provide the full step-by-step evaluation trace as
required by the skill rules, maintaining the call stack and environment in
your JSON state. If a step requires a choice (If/Else), evaluate the
condition based on your current state and proceed with the correct branch.
You must trace execution node-by-node from the AST, and ensure all identifier
names and literal values in your state match the AST exactly. Do not assume
names or values based on memory of similar tests.
4. **Strict Citation:** For every single step of the evaluation, explicitly cite
the specific section ID and rule name (e.g.,
`[sec-addition-operator-plus-runtime-semantics-evaluation]`).
5. **Completion Record Handling:** Always explicitly unwrap or propagate
Completion Records (`[[Type]]`, `[[Value]]`, `[[Target]]`). Pay strict
attention to `ReturnIfAbrupt` shorthands (`?` and `!`).
### B. State Management
- **Formal Machine State:** You **MUST** maintain the state of the abstract
machine (including `executionContextStack`, `environmentRecords`, and `heap`)
using the provided state machine tools. You MUST accurately update the state
using the provided tools for EVERY state change required by the specification.
Do not just describe the state changes in text; you MUST actually call the
corresponding tools to update the machine state! Furthermore, the **state
history** (inspectable via `get_history`) must be correct and complete,
faithfully reflecting all operations performed. Skipping tool calls will
result in an incomplete and incorrect history, which is a violation of this
rule.
### C. Ambiguity
- **Identify Ambiguity:** The spec is not flawless. If you detect an editorial
error, a missing indeterminate form definition, or an undefined sequence,
explicitly flag it.
## 3. Tool Usage & Orchestration SOP
You are equipped with purpose-built MCPs. Use these tools strategically to build
your answers:
> [!IMPORTANT] **Strict Tool Usage Rules:**
>
> 1. **No Guessing Tool Names**: You MUST ONLY use the operation names listed in
> Section II for `object_op` and `env_op`. Do NOT assume a specification
> operation (like `OrdinaryFunctionCreate` or `Call`) is available as a tool
> unless it is explicitly listed here.
> 2. **Flat Arguments**: You MUST pass arguments as flat JSON properties to the
> tools. Do NOT wrap arguments in an `args` or `desc` object unless the
> schema explicitly requires it.
### I. Navigation & Grammar Extraction
- `ecma262_get_operation(name)`: **[RECOMMENDED]** Use this to directly fetch
the algorithm for an abstract operation by name (e.g., `ToObject`, `GetValue`,
`CreateMutableBinding`). **Try this FIRST** whenever you know the name of the
operation you need, as it bypasses search-then-fetch and saves steps.
- `ecma262_get_evaluation(production_name)`: **[RECOMMENDED]** Use this to
directly fetch the evaluation rules for a specific grammar production (e.g.,
`VariableStatement`). This saves steps and is much faster than searching.
- `ecma262_search(query)`: Use this to locate the exact section ID for a syntax
node (e.g., `VariableStatement`) or when you don't know the exact name of the
operation.
- `ecma262_signature(name)` / `ecma262_dependencies(id)`: Use these to map out
the call graph before writing out an evaluation. This ensures you know which
operations you will need to invoke.
- `ecma262_section(id)`: Fetch the actual algorithm steps. Treat these steps as
law.
- `ecma262_lookup(id)`: Resolves the ancestry (parent chain) of a given section
ID, helping to understand its context in the specification hierarchy.
- `ecma262_sections(ids)`: Fetch full HTML content for multiple section IDs at
once to reduce tool calls.
- `ecma262_production(symbol)`: Use this to fetch Syntactic or Lexical grammar
rules (e.g., `StringNumericLiteral` or `AssignmentExpression`) to explain
parsing edge cases.
### II. State Alteration (JSON Scratchpad)
You **MUST** use the following tools to maintain the abstract machine state.
Call `init()` at the start of evaluation. The tool will automatically generate a
unique state file and remember it as the 'current' state file for your session.
For all subsequent state tool calls, you can omit the `state_id` argument, and
it will automatically use the current state file.
- `init()`: Initialize the state with Global Realm, Env, and Context. Call this
at the start of evaluation. It will automatically generate a unique state
file.
> [!NOTE] `init()` initializes the state with the following well-known
> references:
>
> - Realm: `ref:Realm:1`
> - Global Object: `ref:Obj:Global`
> - Global Environment: `ref:Env:Global`
> - Global Object Record: `ref:Env:GlobalObj`
> - Global Declarative Record: `ref:Env:GlobalDecl`
- `push_context(name, realm, lexEnv, varEnv)`: Push a new execution context onto
the stack.
- `pop_context()`: Pop the top execution context.
- `new_environment(type, outerEnv, bindings)`: Create a new environment record
(Declarative, Function, Private, Module).
- `set_binding(envId, name, value)`: Set a binding in an environment.
- `env_op(env_id, operation, name, value)`: Performs operation on Environment
Record (`CreateMutableBinding`, `CreateImmutableBinding`, `InitializeBinding`,
`SetMutableBinding`, `GetBindingValue`, `DeleteBinding`, `HasBinding`,
`BindThisValue`, `HasThisBinding`, `HasSuperBinding`, `GetThisBinding`,
`CreateImportBinding`).
- `object_op(object_id, operation, property_name, value, descriptor)`: Performs
operation on Heap / Object Model (`MakeBasicObject`, `OrdinaryObjectCreate`,
`SetInternalSlot`, `OrdinaryDefineOwnProperty`, `OrdinaryGetPrototypeOf`,
`OrdinarySetPrototypeOf`, `OrdinaryIsExtensible`, `OrdinaryPreventExtensions`,
`OrdinaryGetOwnProperty`, `OrdinaryHasProperty`, `OrdinaryDelete`,
`OrdinaryOwnPropertyKeys`, `OrdinaryGet`, `OrdinarySet`, `OrdinaryCall`,
`OrdinaryConstruct`, `CreateDataProperty`, `OrdinaryFunctionCreate`,
`PrivateFieldAdd`, `PrivateFieldGet`, `PrivateFieldSet`, `CreatePrivateName`,
`ProxyCreate`, `ArrayCreate`, `StringCreate`).
- `update_context(key, value)`: Updates a field in the running execution
context.
- `enqueue_promise_job(job_name, callback_id, args)`: Enqueues a job in the
Promise Job Queue.
- `get_job_queue()`: Returns the current list of pending jobs as a JSON string.
- `dequeue_job()`: Removes and returns the first job from the queue as a JSON
string.
- `get_history(format_type)`: Returns the history of the state. Supported
formats are 'full' and 'diff'.
- **Delta State Reporting:** To reduce verbosity and save context in
conversation messages, you should only report the *changes* (deltas) to the
state in your messages after calling a state tool, while ensuring that the
*full* state is correctly updated and maintained in the state file via the
tools.
> [!IMPORTANT] **Private Fields Scoping & Shadowing:** To support private fields
> correctly, you MUST use `object_op` with operation `"CreatePrivateName"` to
> generate a unique Private Name identifier. Use this returned identifier as the
> key (`property_name`) in `PrivateFieldAdd`, `PrivateFieldGet`, and
> `PrivateFieldSet` operations.
> [!IMPORTANT] **Proxies and Exotic Objects:** Operations like `OrdinaryGet`,
> `OrdinarySet`, `OrdinaryHasProperty`, and `OrdinaryDelete` act as the spec's
> `[[Get]]`, `[[Set]]`, `[[HasProperty]]`, and `[[Delete]]` dispatchers.
>
> - If they encounter a **Proxy** object, they will return a JSON object with
> `"status": "requires_proxy_trap"`. You MUST read this status and follow the
> instructions to invoke the appropriate trap on the handler object manually
> using `OrdinaryCall`.
> - If they encounter a **String** object, they handle indexed access natively.
> - If they encounter an **unsupported exotic object**, they will return
> `"status": "unsupported_exotic_object"`. You MUST read the instructions in
> the response and follow the spec for that operation manually!
### III. Tool Usage Examples
#### 1. Creating Object Literals with Methods
To create an object literal like `{ a: 1, b() { return 2; } }`:
1. Create the target object: `object_op(..., "MakeBasicObject")` -> returns
`ref:Obj:1`.
2. Define data property `a`:
`object_op("ref:Obj:1", "OrdinaryDefineOwnProperty", "a", descriptor={"value": 1, "writable": true, "enumerable": true, "configurable": true})`.
3. Define method `b`: a. Create function object:
`object_op(..., "MakeBasicObject", descriptor={"internalSlots": ["[[Call]]"]})`
-> returns `ref:Obj:2`. b. Define property `b` on target:
`object_op("ref:Obj:1", "OrdinaryDefineOwnProperty", "b", descriptor={"value": "ref:Obj:2", "writable": true, "enumerable": false, "configurable": true})`.
#### 2. Managing Environments and Contexts
When entering a new function or block scope:
1. Create the environment:
`new_environment("Declarative", outerEnv="ref:Env:Current")` -> returns
`ref:Env:5`.
2. If it's a function call, push a new context:
`push_context("myFunction", "ref:Realm:1", lexEnv="ref:Env:5", varEnv="ref:Env:5")`.
3. Bind parameters or variables in the new environment using
`env_op("ref:Env:5", "CreateMutableBinding", "x")` and `InitializeBinding`.
4. Upon exiting, pop the context if one was pushed: `pop_context()`.
#### 3. Managing the Job Queue (Async/Promises)
When evaluating code that schedules microtasks:
1. Enqueue the job:
`enqueue_promise_job("ResumeAsyncFunction", "ref:Obj:Callback", ["arg1"])`.
2. When the main script finishes, inspect the queue: `get_job_queue()`.
3. Dequeue the next job: `dequeue_job()`.
4. Simulate the execution of that job by pushing a new context and evaluating
the closure!
## 4. Output Formatting Rules
- Use **Markdown** extensively.
- Format code blocks using `javascript` or `ecmascript`.
- Represent spec-internal types clearly. Use double brackets for internal
slots/methods and records.
- Use italics for algorithmic variables and bold for specification types.
- When you have completed the formal evaluation, you MUST output the marker
`== SUMMARY ==` on its own line, followed by a summary of the execution in the
prescribed format.
## 5. System Integrity
- **Handling Undefined Functions**: Treat as `ReferenceError` unless global
binding exists.
- **Do Not Assume Execution Order**: Verify exact sequence by reading the spec.
- **Look Up Before Speculating**: Always use tools to look up spec sections.
deps/v8/agents/skills/env-abstraction/SKILL.md
Vendored
+57
View File
@@ -0,0 +1,57 @@
---
name: env-abstraction
description: Handles abstraction of environment-specific commands between Jetski and Gemini-CLI. Use when switching execution context between local terminal environments. Do not use for debugging logic issues.
---
# Environment Abstraction Skill
This skill provides a layer of abstraction over environment-specific tools and
commands, allowing skills to be reused across different platforms like `jetski`
and `gemini-cli`.
## Core Principles
1. **Decoupling**: Keep tool calls independent from platform specific
implementations inside general workflow skills.
2. **Detection**: Determine the environment at startup (e.g., via environment
variables or tool availability).
3. **Mapping**: Map abstract actions to concrete commands or tool calls based on
the environment.
## Environment Definitions
### Jetski Environment
- **Characteristics**: Rich set of specialized tools (e.g., `code_search`,
`moma_search`, `gdb-mcp`, `v8-utils`).
- **Usage**: Prefer specialized tools over generic shell commands to maximize
efficiency and respect workspace constraints (e.g., avoid heavy searches in
large workspaces).
### Gemini-CLI Environment
- **Characteristics**: May rely more on standard shell commands or a different
set of MCP servers.
- **Usage**: Fall back to standard tools like `grep`, `find`, or standard `gdb`
via `run_command` if specialized Jetski tools are unavailable.
## Abstract Action Mapping
When performing common actions, refer to this mapping to choose the correct
tool:
| Abstract Action | Jetski Implementation | Gemini-CLI Implementation (Fallback)
| | :--- | :--- | :--- | | **Code Search** | `code_search` | `grep_search` (if
outside Google3) or standard `grep` | | **File Search** | `find_by_name` (if
safe) | Standard `find` or `fd` | | **Debugging** | `gdb-mcp` | Standard `gdb`
via `run_command` | | **Building** | `tools/dev/gm.py` (use
`use_remoteexec=true`) | `tools/dev/gm.py` | | **Testing** |
`tools/run-tests.py` | `tools/run-tests.py` | | **Starting Agents** |
`invoke_subagent` (tool) | `agentapi new-conversation` (CLI) |
## Implementation Guidelines
- When writing or updating skills, refer to actions by their abstract names.
- Check for the existence of specialized tools before falling back to generic
commands.
- Document any environment-specific assumptions in the skill file.
deps/v8/agents/skills/header-cycle-breaker/SKILL.md
Vendored
+69
View File
@@ -0,0 +1,69 @@
---
name: header-cycle-breaker
description: Guide for breaking cyclic dependencies in V8 headers and resolving cascade IWYU failures.
---
# Header Cycle Breaker Skill
This skill outlines the systematic approach to breaking cyclic dependencies in
V8 headers, specifically focusing on moving heavy inline includes to more
localized `.cc` files or non-inline headers, and resolving the resulting cascade
of "undefined inline function" errors (IWYU - Include What You Use style).
## When to Use
Use this skill when:
- You are tasked with breaking a header cycle in V8 (e.g., core-to-wasm cycle).
- You need to remove an `-inl.h` include from another `-inl.h` or `.h` file.
- You encounter a flood of `[-Werror,-Wundefined-inline]` errors after modifying
a heavy header.
## Workflow
### Phase 1: Identification and Cycle Breaking
1. **Identify the cycle**: Use tools or subagents to map the include graph and
find the cyclic path.
2. **Plan the break**: Identify a point where an `-inl.h` can be replaced with
its non-inline counterpart (`.h`) or where an include can be moved entirely
to implementation files.
3. **Apply the break**: Modify the header file to break the cycle.
### Phase 2: Resolving the Cascade (IWYU)
Breaking a heavy include chain will cause many implementation files (`.cc`) and
even generated files to fail because they were relying on transitive includes
for inline definitions.
1. **Do not panic**: Expect tens or hundreds of compilation errors initially.
2. **Aggressive Delegation**: Spawn subagents for independent file failures.
Prompt them to identify missing headers for specific undefined symbols.
3. **IWYU Application**: For each failing file:
- Identify which inline method is undefined.
- Find which `-inl.h` file defines it.
- Include that `-inl.h` file directly in the failing `.cc` file, preferably
within appropriate guards (e.g., `#if V8_ENABLE_WEBASSEMBLY`).
4. **Repeat until clean**: Build, fix, and build again. This is an iterative
process.
### Phase 3: Special Case - Generated Files
If a generated file (e.g., `objects-printer.cc`) fails with undefined inline
methods:
1. **Trace to generator**: Realize that editing the generated file is temporary.
Find the source generator (e.g., in `src/torque/`).
2. **Modify the generator**: Update the generator code to emit the necessary
`#include` statements in the files it generates.
3. **Rebuild the generator**: Recompile the tool (e.g., Torque) and let the
build system regenerate the files.
## Best Practices
- **Keep files isolated**: Do not revert the cycle-breaking change when you see
cascade errors. Push through by fixing the files.
- **Use guards**: Always wrap Wasm-specific includes in
`#if V8_ENABLE_WEBASSEMBLY`.
- **Check trait caching**: Be aware of C++ trait caching issues if you encounter
weird subtyping errors during header reorganization.
deps/v8/agents/skills/jsvu/SKILL.md
Vendored
+34
View File
@@ -0,0 +1,34 @@
---
name: jsvu
description: How to use jsvu for cross-engine testing.
---
# JSVU (JavaScript engine Version Updater)
Use `jsvu` to install and test across multiple JavaScript engines (e.g., v8,
spidermonkey, javascriptcore, chakra).
## Installation and Setup
For non-interactive installation and updating of specific engines on Linux, run:
```bash
npx jsvu --os=linux64 --engines=v8,spidermonkey,javascriptcore
```
You can customize the `--engines` flag with the engines you wish to test (e.g.,
`v8,v8-debug,spidermonkey,javascriptcore,graaljs`).
## Running Engines
Once installed, the engines are available in `~/.jsvu/bin/`. You can run them
directly:
```bash
~/.jsvu/bin/v8 my_test.js
~/.jsvu/bin/spidermonkey my_test.js
~/.jsvu/bin/javascriptcore my_test.js
```
This allows you to easily cross-reference behaviors and bugs against other major
JS engines.
deps/v8/agents/skills/minimize-reproducer/SKILL.md
Vendored
+99
View File
@@ -0,0 +1,99 @@
---
name: minimize-reproducer
description: Use this when you need to minimize a complex or bloated JavaScript test case (e.g., from a fuzzer or external report) into a minimal, readable reproduction for debugging V8 issues.
---
# Minimize Reproducer
## Workflow
### 1. Identify the Failure Signature
Before minimizing, understand exactly what "reproduction" looks like.
- **Exact Command:** e.g., \`out/x64.release/d8 --fuzzing poc.js\`
- **Failure Type:** Crash (segfault, abort), Assertion failure, Sandbox
violation, or Incorrect output.
- **Stability Check:** Initially check how stable the reproduction is. If it's
flaky, you'll need to run it multiple times at every step. Use the bundled
\`repro_check.sh\` script.
### 2. Command-Line Flag Minimization
Find the minimal set of V8 flags required to reproduce the issue.
- **Batch Removal:** Start by removing larger batches of flags (e.g., all flags
starting with \`--no-\` or all optimization flags).
- **One-by-One:** Progressively remove individual flags until only the essential
ones remain.
- **Common Critical Flags:** Pay attention to flags like \`--sandbox-fuzzing\`,
\`--memory-corruption-via-watchpoints\`, or \`--turbofan\`, as these often
control the underlying feature being tested.
- **Validation:** Test reproduction after every step. If it stops failing,
restore the last flag removed.
### 3. File Minimization (The Iterative Phase)
Reduce the input JavaScript file systematically. Always work on a copy (e.g.,
\`poc-copy.js\`) and maintain a \`poc-min.js\` as your "best known" version.
- **Remove Large Blocks:** Start by removing entire functions, classes, or large
blocks of code (e.g., fuzzer boilerplate, unused libraries).
- **Binary Search:** If a large block is present, try removing half. If it still
fails, that half was unnecessary.
- **Remove Individual Lines:** Once large blocks are gone, try removing
individual lines.
- **Inline Functions:** If a function is called only once, inline its content
and remove the definition.
- **Simplify Wrappers:** Remove \`try-catch\` blocks but retain the code inside
the \`try\` block.
- **Stabilize with Loops:** If a reproduction is flaky (e.g., it only fails 10%
of the time), add a loop around the triggering logic to increase the failure
probability to 100%.
### 4. Wasm Minimization
WebAssembly reproductions often start as opaque `Uint8Array` blobs. Converting
these to readable `WasmModuleBuilder` JS is critical for understanding and
minimizing the logic.
- **Convert Early with `wami`:** Use the `wami` tool to automatically generate
`WasmModuleBuilder` code from a Wasm binary. This is much less error-prone
than manual conversion.
- **Command:** `out/x64.release/wami --mjsunit input.wasm > poc.js`
- **Handle `WasmModuleBuilder` Specifics:**
- **Recursive Types:** Be careful with recursive type definitions; ensure they
are correctly indexed.
- **Reference Types:** When specifying indices for heap types (e.g., in
`struct.get`), use `wasmRefNullType(typeIndex)` or similar helpers where the
builder expects a type object rather than a raw integer.
- **Signature Validation:** After conversion, verify that the module still
reproduces the original issue. `WasmModuleBuilder` might require minor
manual adjustments if the original binary had subtle validation errors.
### 5. Special API Handling (e.g., Sandbox API)
- **Offset Alignment:** Some APIs (like `Sandbox.markForCorruptionOnAccess`)
require specific alignments (e.g., tagged-size-aligned offsets like 8, 12, or
16).
- **Object Context:** Ensure the object being manipulated (e.g., a String) is
large enough for the offset being targeted. Use `%DebugPrint(obj)` with
`--allow-natives-syntax` to inspect the internal structure.
### 6. Clean and Polish
- **Rename Variables:** Obfuscated names like `__v_0` should be renamed to
something descriptive like `str` or `targetObj`.
- **Readability > Size:** A 20-line file that is easy to understand is better
than a 10-line file that is completely cryptic.
- **Self-Contained:** Ensure the final `poc-min.js` is completely self-contained
and does not rely on external fuzzer libraries unless strictly necessary.
## Guidelines
- **Work on a copy:** Never modify the original reproduction file directly.
- **Validate EVERY change:** A single character change can stop a bug from
reproducing. Always verify.
- **Keep a "Best Version":** Always update your \`-min.js\` file as soon as you
find a smaller working version. This allows you to easily backtrack if a more
aggressive minimization fails.
deps/v8/agents/skills/minimize-reproducer/scripts/repro_check.sh
Vendored Executable
+35
View File
@@ -0,0 +1,35 @@
#!/bin/bash
# A utility to run a command multiple times and report the failure count.
# Usage: ./repro_check.sh "command to run" [count]
COMMAND=$1
COUNT=${2:-10}
FAILURES=0
if [ -z "$COMMAND" ]; then
echo "Usage: $0 \"command\" [count]"
exit 2
fi
echo "Testing reproduction $COUNT times..."
for i in $(seq 1 $COUNT); do
# Run the command and capture exit code.
# We assume a non-zero exit code means reproduction (crash or assertion fail).
$COMMAND > /dev/null 2>&1
if [ $? -ne 0 ]; then
FAILURES=$((FAILURES + 1))
echo -n "F"
else
echo -n "."
fi
done
echo ""
echo "Failures: $FAILURES / $COUNT"
# Exit with 0 if it reproduced at least once, 1 otherwise.
if [ $FAILURES -gt 0 ]; then
exit 0
else
exit 1
fi
deps/v8/agents/skills/orchestrator/SKILL.md
Vendored
+189
View File
@@ -0,0 +1,189 @@
---
name: orchestrator
description: Core skill for task scheduling and multi-agent coordination in V8 development. Use for any multi-step workflow or complex task. Do not use for simple linear tasks.
---
# Orchestrator Skill
This skill defines the behavior of the Main Agent acting as an Orchestrator and
Scheduler. It is mandatory for all complex tasks to ensure efficiency,
parallelism, and correct dependency handling.
## Core Responsibilities
1. **Task Breakdown & DAG Construction**:
- Analyze the high-level goal and break it down into discrete tasks.
- Model tasks as a Directed Acyclic Graph (DAG) where edges represent
dependencies.
- Maintain the DAG in the `task.md` artifact or equivalent representation.
2. **Scheduling & Execution**:
- Identify tasks with satisfied dependencies (in-degree 0) that are ready for
execution.
- Delegate ALL ready tasks to specialized subagents. The Orchestrator agent
MUST NOT execute tasks (like running builds, tests, or benchmarks)
directly.
- Maximize parallelism by running independent tasks concurrently.
3. **Priority & Resource Management**:
- Assign priorities to tasks. Critical path tasks get highest priority.
- Monitor resource usage (context window, active subagents) and throttle
execution if necessary.
- Handle priority inversion: if a high-priority task is blocked on a
low-priority task, elevate the low-priority task.
4. **Communication & Synthesis**:
- Act as the central message broker between subagents.
- Cross-pollinate information: if Subagent A finds something relevant to
Subagent B's task, relay it immediately.
- Synthesize results from multiple streams to form a coherent picture for the
user.
## Rules of Operation
- **Autonomy with Oversight**: Subagents operate with high autonomy ("YOLO"
mode) but must report state changes and critical findings to the Orchestrator.
- **No Independent Branching**: Subagents cannot spawn new top-level workstreams
without Orchestrator approval. They can request the Orchestrator to add new
tasks to the DAG.
- **Continuous Re-evaluation**: As new facts emerge, the Orchestrator must
re-evaluate the DAG, potentially canceling, pausing, or reprioritizing tasks.
- **Update Timer**: The Orchestrator agent MUST set a 30-second recurring timer
using the `schedule` tool to provide synthesized updates to the user,
preventing long periods of silence.
- **Responsive Termination**: If the user issues a 'stop' command, immediately
initiate shutdown of all active subagents and background tasks. Hard-kill any
subagents that do not terminate gracefully within 30 seconds.
- **Concept Escalation**: Subagents MUST explicitly highlight unfamiliar
concepts in their reports. The Orchestrator MUST spawn a dedicated inquiry for
these concepts immediately.
- **Eager Subagent Escalation**: Subagents MUST proactively and eagerly ask the
Orchestrator for help or context when encountering unfamiliar concepts or
potential blockers, rather than getting bogged down in localized research.
- **Ambiguous Targets**: If a task target (e.g., a benchmark name, flag, or file
path) is ambiguous or not found in standard lists, the Orchestrator MUST
immediately ask the user for clarification instead of guessing or performing
extensive sequential searches.
- **Inaccessible Attachments/Resources**: If the intake phase detects that
critical attachments (e.g., POC script, flags, or reproduction steps) from a
bug report are inaccessible or redacted, the Orchestrator **MUST** stop
immediately and ask the user to provide them manually.
- **Resumption After Information Provision**: Once the user provides the missing
information, the Orchestrator **MUST** immediately restart the affected
intake/research phase with the new data to ensure all subsequent technical
steps (expert identification, reproduction, etc.) are based on complete
information.
- **Domain Context Awareness**: Do NOT assume terms in a task description refer
to the environment (e.g., assuming "WSL" means the OS) if they could be
domain-specific (e.g., a benchmark name). Verify with domain documentation or
tools first before taking action.
- **Forced Parallelization**: The Orchestrator MUST identify at least two
parallel tracks for any complex task before proceeding with execution. Do not
perform work sequentially if it can be delegated to subagents to maximize
concurrency.
- **Utilize Wait Time**: If a task involves a long wait (e.g., a V8 build), the
Orchestrator MUST schedule independent research or analysis tasks to run in
parallel. Do not let the main agent or subagents go idle or do trivial work if
there are unanswered questions.
- **Environment-Aware Delegation**: When delegating tasks to subagents, use the
appropriate method for the current environment. In `gemini-cli`, use
`agentapi new-conversation` (CLI) instead of the `invoke_subagent` tool, which
may not be available. Make sure to pass critical environment variables
explicitly to the subagent in its prompt, specifically passing `PATH`
containing `depot_tools` and any settings for `remoteexec` (siso).
- **Subagent Isolation Enforcement**: When delegating tasks that involve
modifying code, building, or running tests that could affect the workspace
state, the Orchestrator MUST ensure the task is scheduled in an isolated
worktree. Do not let subagents operate on the main workspace for destructive
or environment-polluting tasks.
- **Post-Task Self-Reflection & Divergence Analysis**: After the task is
complete:
- **Analyze Process**: Review the session logs.
- **Divergence Analysis**: If the final landed fix/result differs from the
agent's initial proposal:
- Identify *why* the initial proposal was rejected or modified.
- Determine if the agent was "too hasty" or missed critical invariants.
- Trace the logical gap in the investigation.
- **Process Refinement**: Formulate proposals to update skills based on
lessons learned, and implement them in separate, dedicated CLs.
- **Workspace and Branch Management**: Always base new branches on a clean
upstream (e.g., `origin/main`). Avoid creating spurious CLs or polluting
existing CLs with unrelated changes. Use isolated worktrees for tasks that
modify the workspace state.
## Specialized Subagents
The Orchestrator delegates tasks to the following specialized subagents:
- **`researcher`**: Prompted to find relevant code, documentation, and
information in the V8 codebase and the web. Reports findings with file paths
and line numbers.
- **`builder`**: Prompted to compile V8 for specified configurations. Can read
files and search code to understand build errors.
- **`tester`**: Prompted to run tests and benchmarks and report results. Can
read files and search code to understand test failures.
- **`debugger`**: Prompted to investigate crashes and unexpected behavior using
GDB and other tools.
## Advanced Scheduling & DAG Management
- **Directed Acyclic Graph (DAG)**: The Orchestrator must maintain the task list
as a DAG to handle dependencies correctly.
- **Dynamic Re-planning**: When a subagent discovers new information or a task
fails, the Orchestrator must dynamically update the DAG (adding, removing, or
reordering tasks).
- **Eager Parallelism**: Identify independent branches of the DAG and execute
them in parallel by spawning multiple subagents or background tasks.
## Handling Priority Inversion
- **Priority Inheritance**: If a high-priority task (e.g., fixing a blocker)
depends on the completion of a low-priority task (e.g., running a clean build
or documentation), the low-priority task must temporarily inherit the higher
priority to resolve the dependency.
- **Resource Contention Awareness**: Ensure that low-priority tasks do not hold
onto exclusive resources (like GDB sessions or specific build targets) needed
by high-priority tasks.
## Fair Scheduling & Starvation Prevention
- **Task Aging**: To prevent low-priority tasks from being indefinitely starved
by a stream of high-priority tasks, increase their priority based on the time
they have spent in the queue.
- **Guaranteed Resource Allocation**: Allocate a small but fixed percentage of
resources or agent attention to lower-priority maintenance or exploratory
tasks.
## Communication and Synthesis Rules
- **Concise User Communication**: Do not over-explain assumptions or potential
confusions to the user. State what the plan is based on the interpreted
context and proceed. Avoid wordy justifications.
- **Structured Reporting**: Subagents must report results in a structured
format, highlighting:
- Key findings or answers to the assigned question.
- Blockers or new unfamiliar concepts.
- Proposed next steps.
- **Synthesis Before Escalation**: The Orchestrator must not simply pass
subagent reports to the user. It must synthesize the reports from all active
tasks into a coherent state summary and present only the high-level
certainties and decisions to the user.
- **Proactive Context Sharing**: The Orchestrator must relay relevant
discoveries between subagents working on overlapping or dependent tasks to
avoid duplicate work.
## Analogies to Operating System Schedulers
- **Task = Process/Thread**: A discrete unit of work.
- **Dependencies = Synchronization Primitives**: Tasks wait on other tasks to
complete (join).
- **Orchestrator = Kernel Scheduler**: Decides what runs when and on which "CPU"
(subagent).
deps/v8/agents/skills/subagent-env-passing/SKILL.md
Vendored
+33
View File
@@ -0,0 +1,33 @@
---
name: subagent-env-passing
description: Workflow for passing environment variables (like PATH) from the Orchestrator to subagents. Use when spawning subagents that need specific environment variables. Do not use for standard subagent execution.
---
# Subagent Environment Passing Skill
This skill documents how to ensure subagents have access to the correct
environment variables (such as `PATH`) when working in isolated environments
like worktrees.
## Workflow
1. **Retrieve Environment**: The Orchestrator should read the necessary
environment variables from its own context if they are not already known. For
example, run `echo $PATH` to get the current PATH.
2. **Pass to Subagent**: When invoking a subagent, include the environment
variable values in the `Prompt` provided to the subagent.
3. **Instruct Subagent**: Explicitly instruct the subagent to set these
variables in its environment before running tools that depend on them.
## Example Prompt Snippet
```
Please use the following PATH and build settings in your environment:
export PATH=<path_to_depot_tools>:$PATH
export SISO_PROJECT=rbe-chrome-untrusted
```
Note: If building or running `gm.py`, also ensure that `use_remoteexec = true`
is set in your build config/`args.gn`. You can find the correct `SISO_PROJECT`
in `build/config/siso/.sisoenv`.
deps/v8/agents/skills/torque/SKILL.md
Vendored
+85
View File
@@ -0,0 +1,85 @@
---
name: torque
description: Provides expert guidance for navigating, implementing, and verifying V8 Torque (.tq) builtins. Use when modifying or debugging Torque files. Do not use for C++ macro builtins.
---
# V8 Torque
Torque is an Ahead-of-Time (AOT) generator that transforms `.tq` DSL into
highly-optimized C++ CodeStubAssembler (CSA) code, which is then compiled into
the `mksnapshot` binary.
## Execution Pipeline
To debug failures, you must understand its multi-stage build:
1. **Generation**: The Torque compiler reads `.tq` files and generates C++
CodeStubAssembler files (`.cc`, `.h`, `.inc`) in
`out/<config>/gen/torque-generated/`.
2. **Compilation**: `mksnapshot` (or the `d8` build) compiles the generated C++
files.
3. **Snapshotting**: `mksnapshot` executes the generated C++ code (via TurboFan
or Maglev) to emit highly-optimized raw machine code.
4. **Linking**: The machine code is serialized into a snapshot and linked into
V8, meaning Torque builtins run with zero translation overhead at runtime.
## Implementation Patterns
Common Torque syntax, keywords, and linkage definitions:
```cpp
// 1. Type Casting & Checks
const array = Cast<JSArray>(object) otherwise GotoLabel;
if (Is<JSArray>(object)) { ... }
// 2. Control Flow
try {
const smi = Cast<Smi>(input) otherwise IsNotSmi;
} label IsNotSmi deferred {
return runtime::DoSomething(context, input);
}
// 3. Signatures & Keywords
// 'macro': Inlined functions for reusable logic.
transitioning macro Name(implicit context: Context)(arg: JSAny): JSAny
// 'builtin': Non-inlined functions, callable from other builtins or JavaScript.
transitioning builtin Name(implicit context: Context)(arg: JSAny): JSAny
// 'javascript': Marks a builtin as directly callable from JavaScript, with JS linkage.
transitioning javascript builtin Name(js-implicit context: NativeContext, receiver: JSAny)(arg: JSAny): JSAny
// 'transitioning': Indicates a function can cause an object's map to change (e.g. adding properties).
// 'extern': Used to call C++ defined CSA functions from Torque.
extern transitioning macro NameInCpp(Context, JSAny): JSAny;
```
## Mandatory verification workflow
The task is **incomplete** until you successfully execute this sequence:
### 1. Build
Run the `gm.py` wrapper to trigger the Torque generator and C++ compilation.
```bash
tools/dev/gm.py quiet {arch}.{type}
```
(e.g., `x64.optdebug` or `arm64.release`). Use `optdebug` for logic/debugging,
`release` for performance/benchmarking.
### 2. Verify with Tests
Run the relevant test suite (usually `mjsunit` for JavaScript-exposed builtins)
to ensure correctness. Match the `{arch}.{type}` to your build.
```bash
tools/run-tests.py --progress dots --outdir=out/{arch}.{type} mjsunit/<test_name>
```
### 3. Debug (If Necessary)
If the build fails during "Generation", inspect the `.tq` syntax. If it fails
during "Compilation", check the generated C++ in
`out/<config>/gen/torque-generated/`.
deps/v8/agents/skills/v8-ciderg-paths/SKILL.md
Vendored
+18
View File
@@ -0,0 +1,18 @@
---
name: v8-ciderg-paths
description: Adjusts instructions for V8 commands when running in a CiderG Chrome workspace environment. Trigger this when invoking any V8 binaries or running tests in a CiderG checkout.
---
# V8 CiderG Path Adjustments
Because CiderG nests the V8 repository as a component of a larger Chromium
checkout, the build output (`out/` directory) is generated at the root of the
Chromium checkout rather than the V8 directory.
## Path Rules
- When executing from `chromium/v8`, the build directory is located one level up
at `../out/`.
- Adjust any relative binary or test runner paths accordingly.
- **Incorrect:** `out/x64.debug/d8`
- **Correct:** `../out/x64.debug/d8`
deps/v8/agents/skills/v8-commands/SKILL.md
Vendored
+64
View File
@@ -0,0 +1,64 @@
---
name: v8-commands
description: Key commands for building, debugging, and testing in V8. Use when needing command syntax for gm.py, d8 flags, or run-tests.py. Do not use for environment setup.
---
# V8 Key Commands
Use this skill to find the correct commands for common development tasks in V8.
This unifies the commands listed in workspace configuration and ensures
consistent usage.
## Building
V8 uses `gm.py` as a wrapper around GN and Ninja for building.
**Mandatory GN Args & Siso Remote Execution Guardrails**: Always include
`use_remoteexec = true` in your `args.gn` or via `gm.py` flags to ensure builds
utilize remote execution. Remote execution is mandatory in this environment.
**Critical Guardrail (Path Strictness)**: The target output directory must sit
exactly 2 levels deep relative to the project root (e.g., `out/x64.debug` or
`out/x64.release`).
- **Build (Debug):** `tools/dev/gm.py quiet x64.debug tests`
- **Build (Optimized Debug):** `tools/dev/gm.py quiet x64.optdebug tests`
- **Build (Release):** `tools/dev/gm.py quiet x64.release tests`
- **Sync DEPS Options:** Use `tools/dev/gm.py quiet x64.optdebug.d8 --sync` to
sync DEPS when switching between branches. Use the slower `--sync=force`
option if there are still issues with broken DEPS.
*Note: Always pass the `quiet` keyword unless told otherwise to avoid excessive
output.*
## Debugging
Run `d8` with GDB or LLDB for native code debugging.
```bash
# Example of running d8 with gdb
gdb --args out/x64.debug/d8 --my-flag my-script.js
```
### Common Diagnostic Flags
- `--trace-opt`: Log optimized functions.
- `--trace-deopt`: Log when and why functions are deoptimized.
- `--trace-gc`: Log garbage collection events.
- `--allow-natives-syntax`: Enables calling of internal V8 functions (e.g.,
`%OptimizeFunctionOnNextCall(f)`) from JavaScript for testing purposes.
- `--gdbjit`: Allows seeing Maglev graphs or JavaScript code in GDB backtraces.
To debug issues involving code motion disable gdbjit (as it disables code
motion).
A comprehensive list of all flags can be found by running
`out/x64.debug/d8 --help`.
## Testing
For detailed instructions on running tests and interpreting failures, see the
dedicated test execution guidelines.
Key commands summary:
- **Run tests:** `tools/run-tests.py --progress dots --outdir=out/x64.optdebug`
deps/v8/agents/skills/v8-log/SKILL.md
Vendored
+124
View File
@@ -0,0 +1,124 @@
---
name: v8-log
description: Understanding v8.log files.
---
# V8 Log Viewer CLI
A standalone command-line tool for analyzing `v8.log` files. It allows you to
inspect internal state of the V8 JavaScript engine.
## Requirements
This tool requires the V8 shell (`d8`) to be installed and accessible. If no
local d8 build is available it will try to call back to jsvu's d8 in
`~/.jsvu/bin/v8`. You can override this by setting the `V8_PATH` environment
variable.
## Available Commands
Use the following commands to inspect different aspects of the log. Each command
focuses on a specific type of event or structure in the V8 execution profile:
- **`stats`** Prints aggregated statistics of all events found in the log. Use
this to get a quick high-level overview of the log content (e.g., total number
of scripts, functions, ICs, and deopts).
- **`ic`** Lists detailed information about Inline Cache (IC) events. ICs are
used by V8 to optimize property accesses based on type feedback. Use this to
find polymorphic or megamorphic IC misses that might be causing performance
bottlenecks.
- **`script`** Lists all scripts loaded by V8. Use this to find script IDs for
specific source files or to inspect the size of loaded assets.
- **`code`** Lists all code objects created by V8 (e.g., full code, bytecode,
stub handlers). Use this to inspect the generated code entries and their size
for specific functions or builtins.
- **`function`** Lists all compiled functions tracked by V8 and their variants.
A function can have multiple compilation variants (e.g., unoptimized bytecode
and optimized machine code). Use this to see how many times a function was
compiled and at what optimization tiers.
- **`deopt`** Lists all deoptimizations that occurred. Deoptimizations happen
when V8's optimistic assumptions are violated, forcing it to fall back to less
optimized code. Use this to find performance cliffs caused by deopts and
understand why they happened (e.g., insufficient type feedback).
## Usage & Help
To see the full list of common options and specific filter options for any
subcommand, rely on the tool's built-in help system:
```bash
./tools/v8-logviewer --help
```
To see specific help, detailed descriptions, and command-specific filter options
for any subcommand, run:
```bash
./tools/v8-logviewer <command> --help
```
## Logging Flags
To generate a `v8.log` with specific information, you must pass diagnostic flags
to `d8` when running your script.
Here are the most common flags to enable specific log events:
- **`--prof`** Enables execution profiling (ticks). This is required for `stats`
and general profiling analysis.
- **`--log-ic`** (slow) Logs Inline Cache (IC) events. Required for the `ic`
command.
- **`--log-deopt`** Logs deoptimizations. Required for the `deopt` command.
- **`--log-maps`** (slow) Logs map creation and modification events.
- **`--log-code`** Logs code events to the log file without profiling. Useful
for the `code` command.
- **`--log-code-disassemble`** Logs all disassembled code to the log file.
- **`--log-source-code`** Logs source code information.
- **`--log-all`** Enables all logging (very verbose!). Use with caution.
**Example:**
```bash
out/release/d8 --log-all my-script.js
```
This will generate a large v8.log file. It is recommended to use a more targeted
set of flags when possible.
## Examples
List the 10 largest script summaries to see which ones are interesting:
```bash
./tools/v8-logviewer script v8.log --sort=size --limit=10
```
List details for a specific script id:
```bash
./tools/v8-logviewer script v8.log --script-id=170 --details
```
List all functions details for a specific script:
```bash
./tools/v8-logviewer function v8.log --script=example.js
```
List the last 5 deoptimizations:
```bash
./tools/v8-logviewer deopt v8.log --limit=-5
```
Find all optimized code objects for a specific function:
```bash
./tools/v8-logviewer code v8.log --function=myFunction --code-kind=Opt
```
Count how many IC events happened in a specific time window:
```bash
./tools/v8-logviewer ic v8.log --time=500000..600000 --count
```
deps/v8/agents/skills/v8-poc-classification/SKILL.md
Vendored
+142
View File
@@ -0,0 +1,142 @@
---
name: v8-poc-classification
description: Checks if a POC provided by some JS and d8 flags is a vulnerability or just a regular bug.
---
# Skill: V8 POC Classification
Use this skill to determine if a reported Proof-of-Concept (POC) crash is a
security vulnerability or a regular bug through empirical technical analysis.
## Core Mandates
- **Scope Limitation:** This skill is strictly for **technical analysis and
classification**. It does NOT include implementing a fix.
- **Empirical Verification of ALL Claims:** Do not take ANY part of the
reporter's classification or impact claims at face value. Every claim (e.g.,
"arbitrary memory write", "sandbox escape", "silent write") MUST be
empirically verified.
- **Verify with Debuggers:** A claim of memory corruption must be verified by
observing the crash or memory state using debugging tools (GDB).
- **Read vs. Write**: You MUST verify the faulting instruction type.
- **Pointer Control**: Check if faulting addresses or register values are
actually controlled by the attacker (e.g., contain values from the POC).
- **Mandatory Non-ASan Verification:** For any potential security bug, you MUST
verify reproduction on a standard **Release build without ASan/UBSan**.
- **Autonomous Classification:** You are responsible for forming your own
technical conclusion. If your analysis shows it is a `DCHECK` failure or
relies on experimental flags, classify it as a **Bug**.
## Workflow
### 1. Initial Verification & Exhaustive Reproduction
Confirm the bug exists as reported.
- **Action**: Run `d8 <provided-flags> <poc.js>`.
- **Escalation**: If it doesn't reproduce, try multiple revisions (Reporter's
commit and Main) and build configurations (Debug, ASan, Release).
- **Deep Dive**: Capture the initial backtrace and faulting instruction in GDB.
- **Check for Explicit Aborts:** Look for evidence that execution was
intentionally terminated by V8 (e.g., via `SBXCHECK`, `FATAL`, or traps). If
so, this is typically **Intended Behavior** (see guidelines below).
### 2. Security Boundary Investigation (The Filter)
Determine if the bug remains a vulnerability under production restrictions.
- **Action**: Run with `provided_flags + --run-as-[sandbox]-security-poc`.
- **Failure Loop (If reproduction stops)**:
1. **Analyze**: Identify which flag or syntax is restricted. Is it
`--allow-natives-syntax`? Is it an experimental compiler flag?
2. **Heal**: Attempt to rewrite the POC to avoid the restriction.
- *Example*: Replace `%OptimizeFunctionOnNextCall(f)` with a loop that
triggers Tier-up: `for(let i=0; i<10000; i++) f();`.
- *Example*: Replace `%ArrayBufferDetach(b)` with a standard way to
detach/transfer if possible.
3. **Conclude**: If the logic *requires* a restricted feature (like
`--fuzzing` or a non-shipping experimental flag) to trigger the memory
corruption, the report is likely a **Bug**, not a vulnerability.
### 3. Impact Assessment & Minimization
Technical proof of the vulnerability's severity.
- **Minimization**: Strip the POC and flags to the absolute minimum required to
trigger the crash under the security POC flags.
- **Flag Bisection**: If reproduction requires catch-all flags like
`--future`, you MUST identify the minimal set of flags responsible for the
behavior.
- **Identify Implications:** Search `src/flags/flag-definitions.h` for flags
implied by the reported flags.
- **Check Production Defaults:** Verify if the identified flags are enabled
or disabled by default in production.
- **Systematic Testing:** Test each implied flag individually (or in groups)
with the POC to pinpoint the specific optimization or feature at fault.
- **Impact Escalation**: If the bug exists but does NOT cause a crash (e.g., a
"stale value" or "logical type confusion"), you MUST attempt to escalate it to
a memory safety violation. Prove that the logical flaw can bypass V8's
security boundaries.
- **Techniques**: Type Confusion (misleading object layout), OOB Access (stale
length), Pointer Overwrite (overwriting field/loop-carried pointer).
- **Verification**: Run the *minimized* POC on a **Standard Release build
(non-ASan)**.
- If it stops crashing or is caught by a hardened check (`SBXCHECK`, `FATAL`),
classify it as **Intended Behavior** or a **Bug**.
- **Crashing POC for ClusterFuzz**: A crashing POC (segfault) is highly
preferred for ClusterFuzz upload. Always try to provide a standalone `.js`
file that crashes on a Release build.
- **Deep Dive (GDB)**:
- Verify **Attacker Control**: Do registers or memory at the crash site
reflect values set in the POC (e.g., `0x41414141`)?
- **Read vs. Write**: Explicitly identify the primitive.
- **Scope Analysis**: For logical bugs, use tracing flags (e.g.,
`--trace-maglev-graph-building`) to confirm the discrepancy.
- **Component Mapping**: Identify the specific V8 subsystem affected (e.g.,
Maglev, Turbofan, Ignition, WebAssembly) to support component
classification.
### 4. Classification Guidelines
The classification MUST be supported by empirical evidence from the local
reproduction:
- **Local Reproduction Findings**:
- **Status**: Reproduced / Not Reproduced.
- **Reproduction**: `d8 <flags> <poc.js>` (Exact command used locally).
- **Result**: Summarize the result of running the command (output, crash,
sandbox violation, harmless memory access).
- **Build**: The build variant (e.g., x64.release, x64.debug, asan). Always
include the V8 version from `src/utils/version.h` and the specific git hash
using `git rev-parse HEAD` for technical accuracy.
- **Verified Impact**: Summarize the **Verified Impact** (e.g., confirmed OOB
write). If the bug is purely logical and caught by runtime protections (like
`ref.cast` or bounds checks) without crashing, state this clearly.
- **GDB Backtrace**: Include a snippet if it supports the classification.
Summary of rules from [triaging.md](../../../docs/security/triaging.md) based on
the threat model:
#### Regular Bugs (No initial in-sandbox write)
- **Type=Vulnerability**: Production code, enabled by default, survives the
security POC flags (`--run-as-security-poc`).
- **Type=Bug**: Requires experimental flags (not in `--future`), developer
flags, or only triggers a `DCHECK` or reliable `CHECK` (safe termination).
- **Intended Behavior**: Safe termination (e.g., via `SBXCHECK`, `FATAL`, or
hardened libc++ checks).
- **Indicators:** Look for traps like `int3` (x64), `brk #0` (arm64), or calls
to the Abort builtin or the runtime function in the backtrace/disassembly.
Also look for "Fatal error" or "Safely terminating process" in stderr, or
calls to `v8::base::OS::Abort` in the backtrace.
#### Sandbox Bypasses (Starts with in-sandbox write/corruption)
- **Type=Vulnerability**: Demonstration of **write access** outside the sandbox
(e.g., "V8 sandbox violation detected") using `--sandbox-testing`.
- **Intended Behavior**: Read-only bypass, or safe termination ("Caught harmless
memory access violation"). Includes linear OOB writes (e.g., `memset`,
`memcpy`) hitting guard regions, or corrupting trusted objects with
well-formed data of the same type. Also includes breaking internal invariants
using testing-only natives (restricted by `IsEnabledForFuzzing`) if the impact
is safely contained.
deps/v8/agents/skills/v8-profile/SKILL.md
Vendored
+83
View File
@@ -0,0 +1,83 @@
---
name: v8-profile
description: Profiling V8 execution.
---
# V8 Profiling
This skill explains how to profile V8 execution using native tools to understand
where time is spent. Make sure to only profile on a quiet system to get the best
results.
## Linux Profiling
On Linux, prefer using the `./tools/profiling/linux-perf-d8.py` script. This
script automates the process of running Linux `perf` with V8, and critically, it
runs `perf inject --jit` afterwards to ensure that JIT-compiled JavaScript
function names are resolved in the profile.
### Usage
```bash
./tools/profiling/linux-perf-d8.py [OPTIONS] <path_to_d8> [D8_OPTIONS] <script.js> [-- <script_args>]
```
Use the `--help` option and `docs/linux-perf.md` for further information.
**Example:**
```bash
./tools/profiling/linux-perf-d8.py out/release/d8 harness.js -- core.js data.json
```
The script will generate a `.perf.data.jitted` file in the output directory
(defaults to current directory or specified by `--perf-data-dir`).
If you get too few ticks, you can run a script multiple times and combine all
the profiles using `pprof`.
### Analysis
To view the report, use `perf report`:
```bash
perf report --stdio -i path/to/file.perf.data.jitted
```
## Other Platforms (or fallback)
For all other platforms, or when `perf` is not available, use the
platform-specific tick processor script in `./tools/`. These tools analyze the
`v8.log` file generated by V8's built-in profiler.
### Available Scripts
- **Linux:** `./tools/linux-tick-processor`
- **macOS:** `./tools/mac-tick-processor`
- **Windows:** `./tools/windows-tick-processor.bat`
- **FreeBSD:** `./tools/freebsd-tick-processor`
### Usage
1. **Generate the log:** Run `d8` with the `--prof` flag.
```bash
<path_to_d8> --prof <script.js>
```
This generates a `v8.log` file.
2. **Analyze the log:** Run the appropriate script for your platform on the log
file.
```bash
./tools/linux-tick-processor v8.log
```
## Performance Warning
**CRITICAL:** Do NOT use heavy logging flags (like `--trace-ic`,
`--trace-deopt`, `--trace-gc`) in parallel with profiling unless explicitly
investigating those specific events. Heavy logging significantly affects
performance and will distort the profile results, leading to inaccurate
conclusions about where time is spent in normal execution.
deps/v8/agents/skills/v8-regression-testing/SKILL.md
Vendored
+150
View File
@@ -0,0 +1,150 @@
---
name: v8-regression-testing
description: Use this skill when designing, writing, or minimizing regression tests (e.g., mjsunit) for V8 bug fixes
---
# Skill: V8 Regression Testing
Use this skill to design, write, minimize, and refine high-quality regression
tests in the V8 codebase (typically under `test/mjsunit/` or its
component-specific subfolders like `compiler/`, `turboshaft/`, `maglev/`, etc.).
## Core Mandates
- **Mandatory Reproducer Rule**: Unless explicitly specified otherwise by the
user, **every single bug fix in V8 MUST be uploaded with a working reproducer
(regression test)**. Uploading just the fix alone is NEVER acceptable.
- **Semantic Quality**: V8 regression tests must be **semantic
(root-cause-driven)** rather than just **syntactic (fuzzer-driven)**. A
high-quality test case is a clear, human-readable, and robust demonstration of
the specific logical bug or compiler invariant under test, rather than a
fragile, black-box crash script.
- **CRITICAL REPRODUCER CONSTRAINT**: **NEVER** provide a reproducer that does
not actually trigger the issue to the user without **explicitly** telling them
about it.
______________________________________________________________________
## The "From-Scratch" Reproducer Philosophy
When constructing a reproducer for a bug, **always prefer writing it from
scratch based on a deep conceptual understanding of the issue, rather than
starting from a fuzzer-generated crash script and trying to minimize it.**
### Why the Post-Hoc Fuzzer Minimization Trap Fails:
1. **The Black Box Dilemma**: Starting with a fuzzer-generated block of code
means you are constantly guessing which strange construct is necessary. You
are highly likely to retain useless nesting (`__wrapTC`), redundant
try-catches, and magic numbers because you are afraid to break the fragile
reproduction state.
2. **Fragility**: Fuzzer scripts often rely on incidental timings, engine
heuristics, or side effects to trigger a crash. If optimization heuristics
change slightly in a future V8 release, the fuzzer reproducer will silently
break and stop testing the intended bug path.
### The "From-Scratch" Synthesis Approach:
1. **Identify the Root Cause**: Analyze the compiler phase graph, the crash
backtrace, and the failing `DCHECK` or invariant to understand the exact
abstract state machine failure (e.g., "an incorrect type representation
selection, a specific Map transition mismatch, or a loop-carried
side-effect").
2. **Begin with a Blank File**: Open an empty editor. Do not copy-paste the
fuzzer script.
3. **Target the State Directly**: Write the absolute minimum JavaScript
necessary to construct that logical state:
- Use clean, structured object definitions and allocations to establish
target internal structures (such as distinct Maps or Shapes).
- Control the IC feedback vector cleanly by warming it up with specific
types.
- Explicitly trigger the compiler pass with intrinsic calls (e.g.,
`%PrepareFunctionForOptimization`, `%OptimizeFunctionOnNextCall`).
4. **Result**: You produce a clean, robust, perfectly commented, 15-line
reproducer that explicitly tests the underlying logic. It is
self-documenting, easy to maintain, and impervious to unrelated engine
optimization tweaks.
______________________________________________________________________
## Debugging a Failing Reproducer (The Scientific Loop)
When writing a reproducer from scratch, it is common for the first attempt to
**not** trigger the crash. When this happens, do not give up or fall back to
blindly copying the fuzzer script. Instead, treat the reproducer's failure as a
debugging task and enter a scientific feedback loop.
### The Feedback Loop:
1. **Trace the Execution**: Use V8's extensive set of tracing flags to inspect
the JIT/engine pipeline (eg, `--trace-turbo-graph`, `--trace-ic`,
`--trace-deopt`...), and insert custom instruction (eg, using `PrintF`) as
needed if the existing flags are too coarse.
2. **Detect the Detour**: Identify exactly where the execution path diverged
from your expectation. For instance:
- *Did the function deoptimize prematurely due to an unexpected type feedback
change?*
- *Did load elimination optimize away a read that was supposed to trigger a
side effect?*
- *Did a map transition occur too early?*
3. **Analyze the Cause**: Figure out *why* V8 chose that detour.
- What invariant, heuristic, or state in your JavaScript code caused the
compiler to take a different optimization path?
4. **Heal and Steering**: Modify your JavaScript reproducer to block the detour
and steer the compiler back onto the target path (e.g., altering map setups,
introducing fake side effects to prevent load-elimination, or adjusting
argument warming patterns).
[!IMPORTANT] **The Ultimate Conceptual Checkpoint**: If you repeatedly fail to
construct a clean, working reproducer from scratch, **this almost always means
your conceptual understanding of the bug is either incorrect or too shallow.**
Do not waste days trying to brute-force random JavaScript tweaks. When this
checkpoint is hit, you must **go back to the drawing board**, challenge what you
think you know about the bug, and deepen your understanding.
______________________________________________________________________
## Synctatic Principles of a Good Regression Test
### 1. Minimal & "Leaf" Compiler Flags
- **Strict Flag Minimization**: Every flag included in `// Flags: ...` must be
thoroughly understood and strictly necessary to reproduce the issue. Remove
all useless or redundant flags.
- **Prefer "Leaf" Flags over "Compound" Flags**:
- **Bad**: Using `--jit-fuzzing` or `--fuzzing` because it implies a massive,
ever-changing bundle of underlying behaviors.
- **Good**: Identifying and specifying the exact leaf flags responsible (e.g.,
`--no-lazy-feedback-allocation`, `--homomorphic-ic`,
`--stress-concurrent-inlining-attach-code`).
### 2. Human-Friendly Naming
Avoid default fuzzer variable and function names (`__f_0`, `__v_10`, `v17`,
`a6`, `a7`).
- Use **descriptive names** for semantic concepts (`large_arr`, `global_var`,
`testGenerator`).
- Use **clean, standard placeholders** for simple generic logic (`foo`, `bar`,
`obj`, `f`, `x`, `y`).
- Maintain cognitive load at an absolute minimum.
### 3. Absolute Minimization of Code & Boilerplate
- Remove every parameter, variable, block, or helper that does not directly
contribute to reproducing the bug.
- Never leave unused parameters in function signatures, unless absolutely
required to reproduce the issue.
- Do not include catch-all blocks (`catch (e) {}`) or dummy wrapper functions
(`__wrapTC`) unless they are semantically required to trigger the crash path.
### 4. Deterministic Optimization Control
- Avoid spinning CPU-burning loops (e.g., `for (let i = 0; i < 100000; i++)`) to
trigger JIT tier-up, unless the bug specifically relates to loop-scaling or
profiling feedback.
- Use V8 intrinsic compiler controls to force deterministic optimization:
- `%PrepareFunctionForOptimization(foo);`
- `%OptimizeFunctionOnNextCall(foo);` or `%OptimizeMaglevOnNextCall(foo);`
- Make sure `--allow-natives-syntax` is included in the Flags header when using
percent (`%`) intrinsics.
deps/v8/agents/skills/v8-security-triaging/SKILL.md
Vendored
+321
View File
@@ -0,0 +1,321 @@
---
name: v8-security-triaging
description: Guides the initial analysis and impact assessment of a V8 security report, strictly excluding implementation or fixing.
---
# Skill: V8 Security Triaging
Use this skill to orchestrate the initial analysis and impact assessment of a V8
security vulnerability report.
## Core Mandates
- **Strategic Orchestration**: You are the **Orchestrator**. Your goal is to
manage specialized subagents to verify reporter claims empirically while
keeping your own context lean.
- **Technical Skepticism**: Treat all reporter claims (e.g., "OOB write", "RCE",
"Silent Write") as **hypotheses**, not facts. Your primary job is empirical
verification.
- **Mandatory Local Reproduction**: A report MUST NOT be classified as a
"Vulnerability" unless it is empirically reproduced locally (e.g.,
demonstrating a crash, memory corruption, or a clear security boundary
violation). If the provided POC does not reproduce the claimed behavior, do
NOT classify it as a vulnerability. Instead, report that it did not reproduce
in the final report.
- **Scope Limitation**: This skill is strictly for **triaging and impact
analysis**. It does NOT include implementing a fix or creating a CL. Fixing is
a separate task that must be explicitly requested by the user after triage is
complete.
- **No External Actions without Approval**: NEVER upload a CL, post a comment,
or modify issue metadata on Buganizer or Gerrit without explicit user approval
of the exact content and action.
- **Buganizer First**: Use the Buganizer MCP (`render_issue`) as the primary
source of truth. Use `render_issue_with_external` if content is redacted. If
attachment retrieval via `get_attachment_enrichment` fails, **MUST**
immediately attempt retrieval using the `buganizer-cli` skill before asking
the user.
- **Sandbox Bypasses vs. Regular Bugs**:
- **Sandbox Bypass**: Reports that start with in-sandbox memory corruption
(using `--sandbox-testing` or `--expose-memory-corruption-api` or the
Sandbox API). These are strictly governed by the V8 Sandbox threat model.
- **Regular Bug**: Vulnerabilities that do not require an initial in-sandbox
write primitive.
- **Title Accuracy**: If the reporter provided a generic title, identify a more
descriptive and accurate title based on the crash state or root cause.
- **Component Verification**: Propose only actual Buganizer components. Use
`mcp_Buganizer_list_components` to verify existence and
`mcp_Buganizer_get_component` to verify the component path and ID before
posting.
- **Remote Execution Priority**: Always use `use_remoteexec = true` in GN
arguments for all local builds to speed up the process, even if a reporter
provides a configuration where it is set to `false`. Remote execution is
strictly an environmental optimization and does not affect reproduction logic.
- **Environmental Awareness**: During information gathering, identify if the
crash involves **specialized execution modes** (e.g., REPL mode,
`DebugEvaluate`, or experimental features) that might have different security
properties.
- **Attachment Access**: Only attempt to retrieve attachment content (e.g.,
`poc.js`) using the Buganizer MCP tools. If the tools fail, **MUST** ask the
user to provide the content manually. Do not speculatively search for
restricted attachments.
- **ClusterFuzz Check**: Check the issue's comments for indications that the
crash has already been uploaded to ClusterFuzz. If not uploaded, provide the
user with manual upload instructions in Step 5.
- **Exhaustive Verification**: Never classify a bug based solely on the report.
Exhaustive technical verification via `v8-poc-classification` is mandatory.
- **Artifact Preservation**: Before removing a worktree or cleaning up a
session, you MUST identify all generated artifacts (e.g., minimized POCs,
crashing `crash.js` scripts, or logs) and ensure they are either uploaded to
Buganizer or moved to a permanent location outside the worktree if requested
by the user.
- **Official Documentation**: Consult [SECURITY.md](../../../SECURITY.md) for
high-level threat models and entry points. Always refer to
[triaging.md](../../../docs/security/triaging.md) for the definitive rules on
labeling and classification.
- **Strict Subagent Delegation**: To maintain a lean context, the Orchestrator
**MUST NOT** call Buganizer, Gerrit, or local execution tools directly during
Phases 1-4. All technical tasks must be delegated to subagents via
`invoke_agent`. The Orchestrator's role is strictly limited to reviewing
subagent summaries and coordinating the next step.
## Strategic Orchestration Guidelines
When executing a triage task, delegate tactical steps to subagents:
- **Researcher**: Fetching report details, identifying experts
(`find_experts_for_file`), and locating Buganizer components.
- **Builder**: Setting up the environment (`git checkout`) and building specific
variants (Release, ASan, non-ASan).
- **Tester**: Baseline reproduction across multiple configurations and security
boundary checks.
- **Generalist**: POC minimization, flag bisection, and "healing" POCs
(replacing natives with standard JS).
- **Debugger**: Interactive crash analysis in GDB to verify primitives and
attacker control.
## Workflow
### 0. Phase: Prepare isolated worktree
- **Orchestrator Instruction**: "Use v8-workflow skill to create a fresh
worktree (cr-NNN, where NNN is the bug number) and respective branch for
investigation. Choose "Isolated Strategy", don't ask user. Switch to the new
worktree and work there to avoid contamenating current workspace. Use "tmp"
subdirectory for temporary files."
### 1. Phase: Intake (Delegation)
Task the **Researcher** subagent with gathering all necessary data from
Buganizer.
- **Orchestrator Instruction**: "Retrieve the `INVOKER_INFO_SESSION_ID` from the
environment. Invoke the Researcher to render Buganizer issue `<id>`, extract
the POC and d8 flags, find top experts for affected files, and identify the
correct component. Instruct the subagent to return only a concise technical
summary."
- **Conversation ID Persistence**: The Orchestrator MUST store the
`INVOKER_INFO_SESSION_ID` in its current context immediately to ensure the
mandatory first sentence in Phase 5 uses the correct, verified ID.
- **Extraction**: The summary must include the POC script, required `d8` flags,
the reporter's environment (commit hash/version), and the identified
**introduction commit (regression range)**.
- **Version and Commit Identification**: Always retrieve the current V8 version
number from `src/utils/version.h` and the specific git hash using
`git rev-parse HEAD`. Prioritize referencing specific git hashes over generic
terms like "HEAD" in triage reports.
- **Attachment Check**: Ensure the subagent checks for mentioned files (e.g.,
"poc.html", "crash.log") that are NOT in the attachments list. If retrieval of
an attachment via MCP tools fails, the subagent **MUST** use the
`buganizer-cli` (`issues download-attachment`) as a fallback.
- **Stop Condition**: If both MCP and CLI retrieval attempts for critical
attachments (POC, flags, etc.) fail or if they are redacted/inaccessible, the
Orchestrator **MUST** stop immediately and ask the user to provide them
manually before proceeding to Phase 2. This includes asking for the **exact
command line** if a ClusterFuzz report link is inaccessible.
- **Mapping**: Include identified experts and the specific Buganizer component
(e.g., `Blink > JavaScript > Maglev`).
### 2. Phase: Exhaustive Reproduction (Delegation)
Task the **Tester**, **Builder**, and **Generalist** subagents with confirming
the issue. You MUST confirm the bug exists before proceeding.
- **Baseline**: Task **Tester** to reproduce with the reporter's exact flags and
revision.
- **Escalation**: If initial attempt fails, task **Builder** and **Tester** to
verify across Release, Debug, and ASan variants at HEAD.
- **Healing (Initial)**: If still failing, task **Generalist** to analyze and
"heal" the POC for environmental dependencies.
- **Summary**: Review the subagent's reproduction command and result. Stop if
reproduction fails after exhaustive attempts.
### 3. Phase: Security Boundary Verification (Delegation)
Task the **Tester** and **Generalist** to determine if the bug violates a
security boundary.
- **Boundary Check**: Task **Tester** to replace
`--expose-memory-corruption-api` in `reporter_flags` with `--sandbox-testing`
and run with updated `reporter_flags` and `--run-as-[sandbox]-security-poc`.
- **Investigation Loop**: If the crash stops reproducing with the security flag,
task **Generalist** to identify why and attempt to "heal" the POC by replacing
forbidden syntax with standard JS while maintaining the bug trigger.
- **Conclude**: Review the subagent's conclusion on whether the bug is a
security vulnerability or a regular bug.
### 4. Phase: Impact Determination & Minimization (Delegation)
Task the **Debugger**, **Tester**, and **Generalist** to provide technical proof
of impact.
- **Crash/Corruption Priority**: Task **Generalist** to make the POC either
crash or demonstrate clear memory corruption.
- **ClusterFuzz Compatibility (Crash Escalation)**: Because ClusterFuzz requires
a detectable crash (DCHECK, segfault, SIGILL, or int3), you **MUST**
exhaustively pursue a crashing reproducer if the initial POC only proves
silent memory corruption. Task **Builder** and **Tester** to run the POC
against **Debug**, **ASan**, and **UBSan** builds. If no crash occurs
naturally, task **Generalist** to modify the POC to force a crash (e.g., by
overwriting a Map with a garbage pointer) while maintaining the original bug
trigger.
- **Verification**: Task **Tester** to verify on Standard Release and ASan
builds.
- **Minimization**: Task **Generalist** to reduce the POC and flags to the
smallest possible set using the methodology in `v8-poc-classification`.
- **Security Impact Check**: If minimization/bisection shows that a
vulnerability only reproduces with flags disabled in production (e.g., a
developer flag), it should be classified as `Security_Impact-None`.
- **Deep Dive**: Task **Debugger** to capture the crash in GDB and verify the
primitive (Read/Write) and attacker control. Review the provided backtrace.
### 5. Phase: Drafting Findings
Draft a concise synthesis based on verified subagent findings.
- **Mandatory First Sentence**: "This analysis is AI-generated using the
`v8-security-triaging` skill (Conversation ID: `<id>`)." You **MUST** retrieve
the `<id>` from the `INVOKER_INFO_SESSION_ID` environment variable. The
variable must always be present.
- **Formatting Requirement**: Use a **bulleted list** format for the main points
(Status, Classification, Rationale, etc.) and ensure there are **double line
breaks** between each list item for optimal rendering in Buganizer. If a list
item has sub-bullets (specifically in 'Local Reproduction Findings'), they
**MUST** be indented by **at least four spaces** and **MUST NOT** be separated
by double line breaks within the same nested list.
- **Content**:
- **Classification**: Vulnerability / Bug / Not a Bug (Intended Behavior) /
Failed to Reproduce. **MANDATORY**: Only classify as "Vulnerability" if
local reproduction was successful. If reproduction fails, classify as
"Failed to Reproduce".
- **Security Impact**: Classify as "**None**" (experimental, disabled) or
"**Yes**" (shipping, web-exploitable) with a mandatory technical rationale;
omit specific channel labels (e.g., `Security_Impact-Stable`) as they are
auto-derived from `FoundIn`. Skip or simplify the CVSS vector unless
requested.
- **Proposed Severity**: Provide the proposed severity (e.g., `S1`) based on
[triaging.md](../../../docs/security/triaging.md) and Chromium guidelines.
- **Introduced In / Regression Range**: Provide the commit or version where
the vulnerability was introduced, if identifiable.
- **Rationale**: Explain the technical conclusion. For sandbox bypasses,
explicitly state if it violates the threat model.
- **Local Reproduction Findings**: Follow the structure and mandatory fields
defined in the **Classification Guidelines** of `v8-poc-classification`.
Ensure all technical data (Status, Reproduction command, Result, Build
(including version from `src/utils/version.h` and git hash), Verified
Impact, and optional GDB Backtrace) is included here.
- **Proposed Owner**: Based on expert discovery. Include a very short (half
sentence) explanation for the choice (e.g., "author of affected code",
"primary maintainer of subsystem").
- **Proposed Component**: Propose the most specific Buganizer component
possible (e.g., `Parser`, `Maglev`, `Turbofan`) if the current component is
the top-level V8 engine component or is otherwise incorrect. Include the
component path and ID.
- **Proposed Title**: If the current title is generic, propose a more
descriptive title.
- **ClusterFuzz Upload Info (User Only)**: If a real crash or memory
corruption is confirmed and it has NOT yet been uploaded to ClusterFuzz,
provide all necessary details for a manual upload (repro file, job name,
issue ID, and flags) to the user. Explicitly advise the user to perform the
upload.
### 6. Phase: Verification & Self-Correction (Audit)
Task a **Generalist** subagent acting as a "Security Triage Auditor" to review
the draft.
- **Orchestrator Instruction**: "Audit the attached triage draft against
`docs/security/triaging.md` and the Technical Quality Checklist. Ensure the
classification is technically sound and the formatting is correct. If errors
are found, distinguish between text-only corrections and missing technical
work."
- **Loop-back Mandate**: If the Auditor identifies missing technical evidence
(e.g., skipped boundary checks, missing GDB analysis, or unverified impact on
Release builds), the Orchestrator **MUST** return to the relevant previous
phase (Phase 2, 3, or 4) and re-delegate the work to the appropriate subagent
before proceeding.
- **Review**: The auditor must verify that:
- The classification (Vulnerability vs. Bug) is consistent with the
reproduction results (e.g., if it needs experimental flags, it's a Bug).
- The "Local Reproduction Findings" section contains the exact d8 command, V8
version, git hash, and the observed result.
- The formatting (double line breaks between top-level list items AND
four-space indented sub-bullets for findings without internal double line
breaks) is strictly followed.
- The conversation ID is correct and matches the `INVOKER_INFO_SESSION_ID`
environment variable. The auditor MUST run
`env | grep INVOKER_INFO_SESSION_ID` to verify this independently.
- **Action**: Present the *audited and verified* analysis to the user for
approval ONLY after all technical gaps identified by the auditor have been
addressed.
### 7. Phase: Cleanup & Preservation
Finalize the session by securing artifacts and cleaning up the environment.
- **Artifact Check**: Identify all important generated files (e.g., `crash.js`,
`minimized_poc.js`, or specialized logs).
- **Preservation**: If any important artifacts were generated in the worktree,
you **MUST** ask the user if they would like to preserve them in the main
repository directory before deleting the worktree.
- **Worktree Removal**: Once artifacts are preserved or the user confirms they
are no longer needed, use the `v8-workflow` skill to remove the isolated
worktree and branch.
## Technical Quality Checklist
- [ ] **Classification Accuracy**: Does the result match the criteria in
`docs/security/triaging.md`? (e.g., `nullptr` is a Bug, safe termination is
Intended Behavior).
- [ ] **Boundary Verification**: Was the POC tested with the security filter
flag (`--run-as-[sandbox]-security-poc`)?
- [ ] **Mandatory Data**: Are the V8 version and git hash included in the Build
description?
- [ ] **Formatting**: Are there double line breaks between all top-level
bulleted list items? Are sub-bullets indented by at least four spaces without
internal double line breaks?
- [ ] **Impact Evidence**: Is the Verified Impact supported by GDB analysis or
ASan/UBSan logs?
- [ ] **Component Mapping**: Does the proposed component exist with the stated
ID and is it the most specific one available (not just `V8`)?
## Common Misclassification Pitfalls
- **Experimental Flags**: If a bug requires `--experimental-*` flags and is not
part of `--future` or `--wasm-staging`, it is a **Bug**, not a Vulnerability.
- **DCHECK vs. CHECK**: `DCHECK` failures are **Bugs**. `CHECK` failures are
**Intended Behavior** (safe termination) unless they are in-sandbox and part
of a sandbox bypass claim.
- **Sandbox Read-only**: Sandbox bypasses that only provide **Read** access are
currently **Bugs**.
- **d8-only Flags**: Bugs requiring flags like `--shell` or `--isolate` are
**Bugs**.
- **nullptr Dereference**: Always a **Bug**, never a Vulnerability.
deps/v8/agents/skills/v8-setup/SKILL.md
Vendored
+79
View File
@@ -0,0 +1,79 @@
---
name: v8-setup
description: Handles missing dependencies and configuration for V8 tools. Use when encountering missing tools, test runners, or workspace symlinks. Do not use for C++ coding issues.
---
# Skill: V8 Setup
Use this skill to handle missing dependencies or configuration issues in the V8
environment.
## Workspace Setup for Jetski
Jetski often expects a `.agents` directory or symlink in the V8 workspace root
to find skills and rules.
- **Missing `.agents`**: If the workspace only has `agents` (no dot) and
`.agents` is missing:
- **Suggest symlinking individual files**: Advise the user to create
individual symlinks for each skill and rule file inside `.agents/skills/`
and `.agents/rules/` from the shared `agents/` directory, rather than
symlinking the whole folders. This allows the user to mix shared skills with
private ones in the same directory.
- This ensures tools can find the shared skills while preserving the user's
ability to customize `.agents`.
## Installation and Configuration of Specialized Tools
The V8 environment relies on specialized tools and MCP servers for advanced
workflows. If they are missing, follow these guidelines:
### 1. Crossbench
Crossbench is the central benchmark runner.
- **Check**: Ask the user for the location of the Crossbench directory if not
found in a standard location.
- **Installation**: If missing, suggest the user to fetch it using `depot_tools`
or clone it from Chromium sources:
```bash
fetch crossbench
# or
git clone https://chromium.googlesource.com/crossbench
```
- **Configuration**:
- Check if `cb.py` is executable. You can usually run it directly by
referencing its full path: `/path/to/crossbench/cb.py`.
- **MCP Server Installation**:
- To install `crossbench-mcp`, add it to `mcp_config.json` pointing directly
to the executable `cb.py`:
```json
"crossbench-mcp": {
"command": "/path/to/crossbench/cb.py",
"args": [
"mcp"
]
}
```
- It will automatically use the managed environment if run in an environment
where `vpython3` is available (like `depot_tools`).
### 2. MCP Servers (v8-utils, gdb-mcp, buganizerMcp, clangd-mcp)
These servers provide advanced capabilities like benchmark running, debugging,
and issue tracking.
- **Check**: Verify if they are listed in the available MCP servers at the start
of the conversation.
- **Setup/Configuration**:
- If missing, you cannot install them directly. You MUST ask the user to
enable or configure them in their Jetski settings.
- **clangd-mcp**: Ensure `compile_commands.json` is generated.
- **gdb-mcp**: Requires GDB to be installed on the host.
- **v8-utils**: Provides tools like `jsb_run_bench` and `v8log_analyze`.
- **Missing Dependencies**: If a required tool (like `poetry` for Crossbench) is
missing or failing, do NOT try to install it yourself. Follow the fallback
advice in the specific workflow skill or ask the user for guidance.
deps/v8/agents/skills/v8-structure/SKILL.md
Vendored
+104
View File
@@ -0,0 +1,104 @@
---
name: v8-structure
description: Maps the V8 dir/folder structure, component locations, and local documentation. Use when locating specific subsystems, mapping src/ code to docs/ design files, or understanding repository architecture.
---
# V8 Folder Structure
Use this skill to understand the layout of the V8 repository and locate specific
components.
## Main Directories
- `src/`: The main source folder providing the implementation of the virtual
machine. Key subdirectories include:
- `src/api/`: Implements the V8 public C++ API, as declared in `include/`.
- `src/ast/`: Defines the Abstract Syntax Tree (AST) used to represent parsed
JavaScript, including nodes, scopes, and variables.
- `src/base/`: Provides fundamental, low-level utilities, data structures, and
a platform abstraction layer for the entire V8 project.
- `src/baseline/`: Implements the Sparkplug baseline compiler, which generates
machine code directly from bytecode for a fast performance boost.
- `src/bigint/`: The implementation of BigInt operations.
- `src/builtins/`: Implementation of JavaScript built-in functions (e.g.,
`Array.prototype.map`).
- `src/codegen/`: Code generation, including direct machine code generation
via macro assemblers, higher level codegen via CodeStubAssembler,
definitions of machine code metadata like safepoint tables and source
position tables, and `compiler.cc` which defines entry points into the
compilers. This contains subdirectories for architecture specific
implementations, which should be kept in sync with each other as much as
possible.
- `src/common/`: Common definitions and utilities.
- `src/compiler/`: The TurboFan optimizing compiler, including the Turboshaft
CFG compiler.
- `src/d8/`: The `d8` shell implementation, for running V8 in a CLI.
- `src/debug/`: The debugger and debug protocol implementation.
- `src/deoptimizer/`: The deoptimizer implementation, which translates
optimized frames into unoptimized ones.
- `src/execution/`: The definitions of the execution environment, including
the Isolate, frame definitions, microtasks, stack guards, tiering, and
on-stack argument handling.
- `src/handles/`: The handle implementation for GC-safe object references.
- `src/heap/`: The garbage collector and memory management code.
- `src/ic/`: The Inline Caching implementation.
- `src/init/`: The V8 initialization code.
- `src/inspector/`: The inspector protocol implementation.
- `src/interpreter/`: The Ignition bytecode compiler and interpreter.
- `src/json/`: The JSON parser and serializer.
- `src/libplatform/`: The platform abstraction layer, for task runners and
worker threads.
- `src/logging/`: The logging implementation.
- `src/maglev/`: The Maglev mid-tier optimizing compiler.
- `src/numbers/`: Implementations of various numeric operations.
- `src/objects/`: The representation and behaviour of V8 internal and
JavaScript objects.
- `src/parsing/`: The parser and scanner implementation.
- `src/profiler/`: The in-process profiler implementations, for heap
snapshots, allocation tracking, and a sampling CPU profiler.
- `src/regexp/`: The regular expression implementation. This contains
subdirectories for architecture specific implementations, which should be
kept in sync with each other as much as possible.
- `src/runtime/`: C++ functions that can be called from JavaScript at runtime.
- `src/sandbox/`: The implementation of the sandbox, which is a security
feature that attempts to limit V8 memory operations to be within a single
guarded virtual memory allocation, such that corruptions of objects within
the sandbox cannot lead to corruption of objects outside of it.
- `src/snapshot/`: The snapshot implementation, for both the startup snapshot
(read-only, startup heap, and startup context), as well as the
code-serializer, which generates code caches for caching of user script
code.
- `src/strings/`: Implementations of string helpers, such as predicates for
characters, unicode processing, hashing and string building.
- `src/torque/`: The Torque language implementation.
- `src/tracing/`: The tracing implementation.
- `src/trap-handler/`: Implementations of trap handlers.
- `src/wasm/`: The WebAssembly implementation.
- `src/zone/`: The implementation of a simple bump-pointer region-based zone
allocator.
- `test/`: Folder containing most of the tests and testing code.
- `include/`: Folder containing all of V8's publicAPI that is used when V8 is
embedded in other projects such as e.g. the Blink rendering engine.
- `out/`: Folder containing the results of a build. Usually organized in sub
folders for the respective configurations.
- `docs/`: Contains V8 documentation, including high-level, cross-cutting
concept guides at the root, and subsystem-specific directories.
- **Root Documentation**: Documents cross-cutting concerns such as embedding
(`docs/embed.md`), debugging (`docs/gdb.md`), profiling (`docs/profile.md`),
security mitigations (`docs/untrusted-code-mitigations.md`), and building V8
(`docs/build.md`).
- **Subsystem Directories** (often containing deep design docs):
- `docs/builtins/`: V8 built-ins and CodeStubAssembler.
- `docs/codegen/`: Code generation.
- `docs/compiler/`: Compilers (Sparkplug, Maglev, TurboFan, Turboshaft).
- `docs/heap/`: Memory management and Garbage Collector.
- `docs/interpreter/`: Ignition interpreter.
- `docs/objects/`: Object layout and Map representations.
- `docs/parsing/`: JavaScript parsing and AST.
- `docs/regexp/`: Regular expression engine.
- `docs/runtime/`: Runtime functions and execution model.
- `docs/sandbox/`: V8 Security Sandbox.
- `docs/security/`: Security triaging and design principles.
- `docs/snapshot/`: Snapshot and serialization.
- `docs/torque/`: Torque language and builtins.
- `docs/wasm/`: WebAssembly implementation.
deps/v8/agents/skills/v8-testing/SKILL.md
Vendored
+84
View File
@@ -0,0 +1,84 @@
---
name: v8-testing
description: Executes and interprets V8 tests. Use when running unittests, cctest, or mjsunit, or when debugging test failures. Do not use for building.
---
# V8 Testing
Use this skill to understand how to run tests in V8 and how to handle failures.
This specializes the general commands for testing.
## Primary Script
The primary script for running tests is `tools/run-tests.py`. You specify the
build output directory and the tests you want to run.
## Key Test Suites
- **unittests**: C++ unit tests for V8's internal components.
- **cctest**: Another, older format for C++ unit tests (deprecated, in the
process of being moved to unittests).
- **mjsunit**: JavaScript-based tests for JavaScript language features and
builtins.
## Running Tests
```bash
# Run all standard tests for the x64.optdebug build
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug
# Run a specific test suite (e.g., cctest)
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest
# Run a specific test file
tools/run-tests.py --progress dots --exit-after-n-failures=5 --outdir=out/x64.optdebug cctest/test-heap
# Manual execution with d8
# Note: mjsunit tests always require test/mjsunit/mjsunit.js.
# tools/run-tests.py prepends this automatically for all tests in mjsunit,
# so you don't need to load it explicitly in the test file.
# For manual d8 execution, you must include it first.
# You can also run tools/run-tests.py with -v to see the full command line used by the runner.
out/x64.optdebug/d8 test/mjsunit/mjsunit.js test/mjsunit/my-test.js
```
*Note: Always pass `--progress dots` so that there is minimal progress
reporting, to avoid cluttering the output.*
## Testing Strategy
To maximize efficiency, use different build configurations based on the task:
- **`x64.debug`**: Use this for deep debugging of a single test case (e.g., with
GDB). It provides full debug information and assertions, but is extremely slow
and **must be avoided** for running `mjsunit` tests in bulk.
- **`x64.optdebug`**: Use this for running the entire test suite. It strikes a
balance between performance and debuggability, allowing for faster full-suite
checks while still preserving assertions.
- **`x64.release`**: Use this for quick checks to verify that a fix works in a
release build or to run benchmarks. It is the fastest but provides the least
debug information.
## Interpreting Failures
If there are any failing tests, they will be reported along their stderr and a
command to reproduce them e.g.
```
=== mjsunit/maglev/regress-429656023 ===
--- stderr ---
#
# Fatal error in ../../src/heap/local-factory.h, line 41
# unreachable code
#
...stack trace...
Received signal 6
Command: out/x64.optdebug/d8 --test test/mjsunit/mjsunit.js test/mjsunit/maglev/regress-429656023.js --random-seed=-190258694 --nohard-abort --verify-heap --allow-natives-syntax
```
You can retry the test either by running the test name with
`tools/run-tests.py`, e.g.
`tools/run-tests.py --progress dots --outdir=out/x64.optdebug mjsunit/maglev/regress-429656023`,
or by running the command directly. When running the command directly, you can
add additional flags to help debug the issue, and you can try running a
different build (e.g. running a debug build if a release build fails).
deps/v8/agents/skills/v8-understanding/SKILL.md
Vendored
+71
View File
@@ -0,0 +1,71 @@
---
name: v8-understanding
description: Guides the methodology for investigating V8 concepts, codebase structure, performance, memory, and architecture. MANDATORY to use whenever triaging bugs, investigating crashes, reading C++ files, analyzing compiler optimizations (Ignition, Maglev, TurboFan, Turboshaft), or doing static research on V8 subsystems. Essential for locating high-level design documents in the local docs/ directory before reading C++ code. Do not use for raw build commands or Git workflows.
---
# V8 Understanding Strategy
Use this skill to explore V8 concepts, components, or optimization logic deeply.
This focuses on the *methodology* of understanding, assuming orchestration is
handled globally by the framework.
## Core Methodology: Hypothesis Testing
To understand complex V8 behavior, follow a scientific approach:
1. **Formulate Hypotheses**: Based on initial reading or symptoms, hypothesize
how a feature works or why a bug occurs.
2. **Design Experiments**: Create small, isolated JavaScript repros or use
specific `d8` flags to test the hypothesis.
3. **Analyze Results**: Use tools like GDB, Turbolizer, or profile logs to
verify if the behavior matches the hypothesis.
4. **Iterate**: Refine the hypothesis based on data.
## Key Areas of Understanding
1. **Performance**:
- Understand execution tiers (Ignition, Maglev, TurboFan).
- Trace how optimizations are applied and why deoptimizations happen.
2. **Memory**:
- Understand object layout (Hidden Classes/Maps).
- Trace garbage collection behavior and allocation patterns.
3. **Architecture & Detailed Interaction**:
- Focus on the detailed interaction between components (e.g., how the Parser
feeds the AST, which feeds Ignition).
- Understand how optimizations interact with core features. Avoid treating
components in isolation.
## Documentation Resources
- **Local Documentation**: Refer to the `docs/` directory in the V8 root for
documentation. It contains content from `v8.dev`, so there is no need to
access the external website or use browser tools. Use local search and file
reading to access it.
- **High-Level & Cross-Cutting Concepts**: Many important design principles,
API designs, and cross-cutting features (e.g., sandboxing, embedding,
debugging, profiling, security) are documented in files directly at the root
of the `docs/` directory (e.g., `docs/embed.md`, `docs/gdb.md`,
`docs/untrusted-code-mitigations.md`). Always scan the root `docs/` folder.
- **Subsystem Docs**: When investigating a specific subsystem, check if there
is a corresponding subdirectory in `docs/` (e.g., `docs/compiler/`,
`docs/heap/`). Do not assume a strict 1:1 directory mapping between `src/`
and `docs/`.
- **Global Docs Search**: As a first step, always run a local search (e.g.
`grep` or find tools) across the entire `docs/` directory to find all files
mentioning the key classes, APIs, or optimization concepts you are
investigating (e.g. search for `BytecodeGenerator` in all `.md` files).
## Workflow
1. **Static Research**:
- Identify the main concepts, subsystems, and classes being investigated.
- **Search globally** in the `docs/` directory for these concepts/classes to
locate relevant design files, whether they live at the root of `docs/` or
in a subsystem subfolder.
- Read the discovered documentation files to build a high-level mental model
*before* reading complex C++ code.
- Read code in `src/` to fill in details.
2. **Dynamic Verification**: Use small tests and tracing flags to confirm the
model.
3. **Red/Blue Team Analysis**: Have one agent/subagent propose an explanation
(Blue) and another try to find counter-examples or flaws in it (Red).
deps/v8/agents/skills/v8-workflow/SKILL.md
Vendored
+58
View File
@@ -0,0 +1,58 @@
---
name: v8-workflow
description: Manages git task isolation and environment setup in V8. Use at the start of any new task or bug fix. Do not use for general C++ editing.
---
# V8 Workflow Skill
This skill defines the standard process for setting up and managing your
development environment in V8.
## 1. Task Initialization (Isolation Strategy)
Before starting any feature or bug fix, you MUST decide on a strategy:
- **Isolated Strategy (Recommended)**: Create a dedicated git worktree and
branch. This prevents cross-contamination between tasks. Use
`create_worktree.sh`.
- **Reuse Strategy**: Work in the current directory and branch.
- Use this only if the user explicitly requests to continue previous work or
prefers a single-branch workflow.
- **Issue Reset**: If starting a *new* task without a worktree, always ask
before resetting the `git cl` issue.
## 2. Path Management in Worktrees
When using an isolated worktree (e.g., `worktrees/task-fix-10010110`), you MUST
ensure that all file-modifying tools (`replace`, `write_file`, etc.) target the
correct directory:
- **Explicit Prefixing**: Always prefix `file_path` arguments with the worktree
directory. For example, use `worktrees/task-fix-10010110/src/wasm/...` instead
of `src/wasm/...`.
- **Tool Context**: Be aware that relative paths starting with `src/` or `test/`
will default to the main repository's root, violating task isolation.
## 3. Environment Setup
Once the branch is ready, ensure your local environment is configured for V8
development:
- **depot_tools**: Ensure it is in your PATH.
- `export PATH=$PATH:$HOME/depot_tools`
- **Output Directory**: Use standard V8 output directories (e.g.,
`out/x64.debug`).
## 4. Available Tools
- **[create_worktree.sh](../../scripts/create_worktree.sh)**: Automates task
isolation and setup. Automatically detects whether the repository is in a
standard Git checkout (creating a Git worktree) or a Rift Btrfs workspace
(forking an isolated Btrfs subvolume). Use this at the start of every new
task.
- **[cleanup_worktree.sh](../../scripts/cleanup_worktree.sh)**: Safely removes
task workspaces (Git worktrees or Rift subvolumes) and prunes remnants once a
CL is landed or abandoned.
deps/v8/agents/skills/wasm-d8-perf/SKILL.md
Vendored
+134
View File
@@ -0,0 +1,134 @@
---
name: wasm-d8-perf
description: Use this skill to reproduce, profile, or analyze WebAssembly (Wasm) execution performance using d8 shell.
---
# WebAssembly Performance Analysis in d8
Reproduce, profile, and analyze Wasm performance using the V8 developer shell
(`d8`).
## 1. Reproduction and Establishing a Baseline
- **Build Configurations**:
- **CRITICAL**: Always use a **`release`** build (e.g., `out/x64.release/d8`)
for benchmarking.
- Use **`optdebug`** (e.g., `out/x64.optdebug/d8`) for disassembling/debugging
(preserves symbols).
- **Measurement Metrics**:
- **Wall time**: Measure execution time (e.g., JS `console.time()`).
- *LLM Tip (Statistical Rigor & Warmup)*: Run 3-5 times; take the
median/average. Ensure code runs in a loop to trigger Turboshaft tier-up
(warmup) before measuring.
- **Resource/CPU**: Use `/usr/bin/time -v` (Wall time, memory) and
`perf stat -d` (cycles, instructions, IPC, branch misses).
- *LLM Tip (perf Fallback)*: If `perf` fails due to permissions (e.g.
`kernel.perf_event_paranoid`), notify the user to adjust settings or
switch to a PMU-enabled environment (gLinux/Cloudtop). Fall back to
`d8 --prof` if needed.
- **GC Overhead**: Use `--trace-gc` to trace garbage collection pauses,
especially if WasmGC is used.
- **Tier Isolation**: Compare performance between execution tiers to understand
the optimization effect.
- Liftoff (Baseline): `d8 --liftoff-only script.js`
- Turboshaft (Optimized): `d8 --no-liftoff script.js`
- *Note*: `--no-liftoff` disables speculative inlining since it skips
Liftoff execution and thus doesn't collect feedback.
## 2. Hotspot Identification
Find where time is spent, what the hottest functions, loops, blocks, or
instructions are, so we focus on that:
- **Linux Perf**: Run `./tools/profiling/linux-perf-d8.py` to get a profile with
JIT symbols resolved, then analyze with `perf report`.
- **V8 Profiler**: Run `d8 --prof script.js` and analyze `v8.log` with
`./tools/linux-tick-processor`.
- **Categorize Hotspots**: Wasm user code, JS code, V8 C++
Runtime/GC/Compilation, or JS/Wasm boundary (wrappers).
## 3. Deep Dive Analysis
### Compilation Overhead
- **Identify Slow to Compile Functions**: Use
`d8 --trace-wasm-compilation-times` and `d8 --turbo-stats-wasm`.
- **Inspect Bytecode**: Build `wami` (`tools/dev/gm.py x64.release wami`) and
disassemble: `out/x64.release/wami --single-wat=<func_index> <path_to_wasm>`
### Wasm Binary Quality & Toolchain
Unoptimized Wasm binary patterns can hurt V8 compilation and execution.
- Ask the user if source code (C++/Rust) is available.
- Check for: huge functions, excessive locals, many branches, or missed static
optimizations.
- Ensure binary is a release build (compiled with `-O3`/`-Os`).
### Execution Performance & Optimization (Deep Dives)
Perform deep dives on hot functions:
- **Turboshaft IR Traces**: Run
`d8 --trace-turbo --trace-turbo-filter=<func_name>`.
- *Context Window*: To keep the context windows clean use `jq`
programmatically:
- List phases: `jq '.phases[].name' turbo-*.json`
- Count nodes:
`jq '.phases[] | {name: .name, node_count: (if (.data | type) == "object" and .data.nodes then (.data.nodes | length) else 0 end)}' turbo-*.json`
- Find ops:
`jq '.phases[] | select(.name == "TurboshaftTypeAssertionsPhase") | select((.data | type) == "object" and .data.nodes) | .data.nodes[] | select(.title | contains("BoundsCheck"))' turbo-*.json`
- **Assembly Profiling**: Run `perf annotate -i file.perf.data.jitted --stdio`
to map hot instructions to bytecode.
- *Instruction Skid*: Account for cycle misattribution; inspect surrounding
instructions and data dependencies.
- **Disassembly & Comments**: Run
`out/x64.optdebug/d8 --print-wasm-code-function-index=<idx> --code-comments`.
- *LLM Tip*: Redirect disassembly output to a file (`> disasm.txt`) to avoid
flooding the terminal.
- **Optimization & Tracing Flags**:
- Inlining: `--trace-wasm-inlining`, `--trace-turbo-inlining`
- Loop Peeling and Unrolling: Enable/disable `--wasm-loop-peeling`,
`--wasm-loop-unrolling` to see an effect of those optimizations.
- Other Optimizations: `--turboshaft-trace-load-elimination`,
`--turboshaft-trace-peeling`, `--turboshaft-trace-unrolling`
- Typing: `--trace-wasm-typer`
- **Inlining & Tiering Budgets**: Scalability tuning flags to adjust
optimizations:
- Tiering up earlier or later: `--wasm-tiering-budget=<value>`.
- Inline more or less aggressively: `--wasm-inlining-budget=<value>`.
- **V8 Flag Discovery**: Search for context-specific flags using
`d8 --help | grep -i <keyword>` or by looking up definitions in
`src/flags/flag-definitions.h` and via `grep`. Refer to `v8-commands` skill
for general usage.
## 4. Synthesis and Reporting
Provide a clear report summarizing:
1. **Hottest Functions**: Contribution and compilation tier (Liftoff vs
Turboshaft).
2. **Inlining Status**: Report Wasm-to-Wasm and JS/Wasm wrapper and body
inlining.
3. **Wasm Input Binary Properties**: Release vs debug, missed static
optimizations, very large functions, or otherwise noteworthy code patterns.
4. **Disassembly & Assembly Hotspots**: Highlight hot instructions and map them
to Wasm bytecode.
5. **Turboshaft Optimization**: Key phases affecting the CFG and any failed
optimizations.
6. **Code Skeleton**: Provide a simplified snippet of the hot block/loop at the
most useful level (source, bytecode, IR, or machine code).
## 5. Experimentation & Verification
Only proceed to this step after your initial report and explicit approval by the
user.
- **Ablation Studies**: Toggle optimizations to measure wall-time impact (e.g.
`--no-wasm-loop-unrolling`, `--no-turboshaft-wasm-load-elimination`,
`--no-wasm-inlining`, `--no-turbo-inline-js-wasm-calls`).
- *LLM Tip*: Present results in a **Before vs. After table**.
- **Wasm Binary/Static Optimization**: Use `wasm-opt -O3` (or `-Os`) if
available on `PATH`, or ask the user to rebuild with different flags.
- **Hypotheses**: Align on potential optimization opportunities with the user
before implementing fixes.
deps/v8/agents/skills/workflow-debugging/SKILL.md
Vendored
+162
View File
@@ -0,0 +1,162 @@
---
name: workflow-debugging
description: Workflow for issue-based debugging in V8. Use when tasked with debugging a specific issue, usually associated with a Buganizer ID or a specific reproduction script. Do not use for performance regressions.
---
# Workflow: Issue Debugging
Use this skill when tasked with debugging a specific issue, usually associated
with a Buganizer ID or a specific reproduction script. This specializes the
general debugging approach for tracked issues.
## Activation Criteria
- User provides an issue ID or Buganizer URL.
- User provides a reproduction script that crashes or behaves unexpectedly.
- The goal is to find a root cause and propose a fix for a specific bug.
## Core Principles (Inherited & Specialized)
1. **Strict Orchestration**: The main agent acts purely as a dispatcher.
Delegate technical tasks.
2. **Eager Parallelism**: Initialize Heavy Infrastructure, Conceptual Triage,
and Static Research in parallel.
3. **Issue Association**: When an issue ID is known, use it to label tests and
commits.
4. **Handling Inaccessible URLs & Missing Info**:
- If a URL cannot be accessed directly (e.g., due to authentication), or if
the intake phase detects that critical attachments (repro script, flags,
etc.) cannot be accessed or are redacted, the Orchestrator **MUST** stop
immediately and ask the user to provide them manually.
- Avoid opening a browser to access the page if it is inaccessible through
tools.
- Use separate, sequential interactive prompts (e.g., via `ask_question` or
direct message to user) to gather missing information:
- **Input 1**: The JavaScript test source code.
- **Input 2**: The relevant `d8` flags or command-line arguments.
- Rely on user-provided reproduction script or flags.
- If the user denies or does not provide the information, seek explicit
guidance on how to proceed.
- Store the test source in the workspace (e.g.,
`scratch/regress-<issue_id>.js`) to avoid modifying the user's environment
directly.
5. **Worktree Isolation**: If you debug with a repository in use (e.g., with
unrelated changes) or debug multiple issues at once you MUST create and
switch to an isolated git worktree using
`agents/scripts/create_worktree.sh <issue_id>` BEFORE running any builds or
tests, to avoid clobbering the main workspace or rebuilding unnecessarily.
6. **Cross-Pollination & Communication**: The Orchestrator MUST actively relay
relevant discoveries and hypotheses between subagents working on overlapping
or related tasks to avoid duplicate work and find matching patterns.
## Workflow
### 1. Triage & Parallel Track Initialization
- Analyze the request and extract the Issue ID if available.
- **Worktree Setup**: If an issue ID is identified, immediately create and
switch to a separate git worktree using
`agents/scripts/create_worktree.sh <issue_id>` to isolate the investigation.
- **Eager Delegation (MANDATORY)**: The Orchestrator MUST proactively spawn
subagents to handle all of the following tracks in PARALLEL:
- **Track A: Heavy Infrastructure**: Spawn a subagent to build `d8` and
prepare GDB/rr in the worktree.
- **Track B: Conceptual Triage**: Spawn a subagent to analyze the reproducing
JS source.
- **Track C: Static Research**: Spawn a subagent to search for related code
and spec text, and understand affected areas super deeply.
### 2. Work Branching
- Spawn subagents for independent dimensions (e.g., Spec vs. Runtime).
### 3. Investigation & Escalation
- **Reproduction Verification (MANDATORY)**: Before launching GDB or doing any
deep debugging, you MUST first execute the reproduction script normally
(without GDB) using your compiled `d8` binary to verify that the crash indeed
reproduces locally. This establishes the baseline.
- Use GDB to inspect crash state.
- Escalate unfamiliar concepts immediately.
### 4. Synthesis
- Combine findings to locate the root cause.
### 5. Fix & Verify
- Propose a fix following V8 Best Practices.
- **Create a Regression Test**: Design and implement a clean, semantic
regression test. This test must be developed and verified to crash/fail on the
unfixed codebase and pass cleanly on the fixed codebase.
- **Architectural Skepticism (MANDATORY)**: Before presenting the fix, the agent
MUST explicitly argue *against* its own proposal.
- *Skepticism Prompt*: "Is this fix too hasty? Does it accidentally disable a
valid optimization path? Am I fixing a symptom (crashing line) rather than
the root cause (invariant violation)?"
- **Deep Reasoning**: If the root cause isn't fully understood, spawn a subagent
to reason deeper about why the failing line exists and what invariant it's
protecting.
- **Verify**: Confirm with tests and `d8` flags. Run tests on both debug and
release builds if possible to ensure no assertions are violated and
performance is not regressed.
### 6. Interactive Review
Before committing or uploading, you MUST present the proposed solution to the
user for review.
- **Present the Diff**: Show the exact code changes proposed.
- **Present the Test**: Show the working regression test file and where it will
be placed. A bug fix must **always** be accompanied by a working regression
test. Proposing a fix without a reproducer is strictly forbidden unless the
user has explicitly waived it.
- **Explain the Root Cause**: Provide a clear explanation of *why* the bug
happened.
- **Share Skepticism Results**: Briefly mention the counter-arguments considered
during the Skepticism phase and why the proposed fix is still the right
choice.
- **Ask for Approval**: Explicitly ask the user if you should proceed with
committing and uploading.
### 7. Commit & Upload (Specialized)
Once the fix is approved by the user:
- **Issue Association in Commits**:
- The commit message must follow the V8 convention.
- It MUST include a `Bug: <issue_id>` line at the bottom.
- Example Commit Message:
```
[compiler] Fix crash in Turboshaft during loop unrolling
The loop unroller failed to handle cases where...
Bug: 12345
```
- **Test Naming and Placement**:
- Name the reproduction test file `regress-<issue_id>.js`.
- If there is no issue ID, use a descriptive name like
`regress-short-description.js`.
- Place the test in the appropriate directory:
- General regressions: `test/mjsunit/regress/`
- Component-specific regressions (if applicable): e.g.,
`test/mjsunit/compiler/regress-12345.js`.
- Ensure the test file contains a standard header:
```javascript
// Copyright 2026 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
// Flags: --allow-natives-syntax --any-other-flags
```
- **Finalization and Upload**:
- Run `git cl format` to ensure style compliance.
- Create the commit locally.
- Follow git-cl rules to upload the change list (CL) to Gerrit.
- Report the CL URL back to the user/caller if the tool output provides it.
deps/v8/agents/skills/workflow-general-debugging/SKILL.md
Vendored
+62
View File
@@ -0,0 +1,62 @@
---
name: workflow-general-debugging
description: Workflow for general debugging tasks without the overhead of issue tracking. Use when investigating crashes, hangs, or unexpected behavior where no specific issue ID is provided. Do not use when issue ID is provided.
---
# Skill: Workflow - General Debugging
Workflow for general debugging tasks in a pristine branch or project work,
without the overhead of issue tracking. Use this skill when investigating
crashes, hangs, or unexpected behavior where no specific issue ID is provided.
## Principles
1. **Lightweight & Focused**: Focus on the immediate problem without the
overhead of issue tracking conventions (e.g., `regress-<id>` naming, `Bug:`
tags) unless requested.
2. **Efficient Investigation**: Prioritize quick root cause analysis using GDB
and targeted code reading over exhaustive documentation.
3. **Pristine Branch Work**: Assume you are working on a clean branch or ongoing
project work where changes are local.
4. **Architectural Skepticism**: Always question your fix. Ensure it addresses
the root cause and not just a symptom.
## Workflow
### 1. Problem Triage
- Reproduce the issue if possible.
- Analyze the symptom (crash, hang, incorrect output).
- If a repro script is available, do not modify it directly. Create a scratch
copy for investigation.
### 2. Static & Dynamic Analysis
- Use `code_search` or `grep_search` to locate relevant code based on stack
traces or symptoms.
- Use GDB (`gdb-mcp`) to inspect runtime state, set breakpoints, and trace
execution.
- Focus on understanding the immediate failure context before expanding the
scope.
### 3. Propose Fix
- Develop a minimal fix targeting the root cause.
- Follow V8 Best Practices.
- **Architectural Skepticism**: Argue against your own proposal. Does it disable
optimizations? Does it violate invariants?
### 4. Verify
- **Create a Regression Test**: Design and implement a clean, semantic
regression test. Verify it fails on the unfixed code and passes cleanly on the
fixed code.
- Verify the fix against the repro or by running relevant unit tests.
- Ensure no new failures are introduced in related areas.
### 5. Finalization
- Format the code using `git cl format`.
- **Present the Fix & Test**: Present both the fix diff and the accompanying
working regression test to the user/main agent.
- Do not create commits or upload CLs unless explicitly requested.
deps/v8/agents/skills/workflow-gerrit-fix/SKILL.md
Vendored
+87
View File
@@ -0,0 +1,87 @@
---
name: workflow-gerrit-fix
description: Workflow for automatically fixing errors or addressing comments on a Gerrit CL requested by the user.
---
# Gerrit Fix & Review Workflow
Use this skill when the user asks to "fix the errors on Gerrit issue X" or
"address reviewer comments on CL X" or similar requests targeting a specific
Gerrit Change List (CL).
## Core Principles
1. **Orchestration**: Do not do the work yourself. Break down the task and
delegate to subagents.
2. **Parallelism**: Always identify at least two parallel tracks (e.g., fixing
known errors vs. inspecting for other issues, or addressing different
comments).
3. **Isolation**: Always operate in a dedicated worktree for the CL.
4. **Reproduction**: Always attempt to reproduce the failure locally before
applying a fix, to ensure the fix is verified.
## Protocol
### 1. Information Gathering
- **CQ Results**: Use `gerrit_cq` (from `v8-utils`) to check Commit Queue
status.
- **Presubmit Errors**: Use `gerrit_get_presubmit_errors` (from `pndMcp`) to
fetch detailed presubmit results.
- **Comments**: Use `gerrit_comments` or `gerrit_list_change_comments` to read
reviewer feedback or robot comments. This is critical when the goal is to
address reviewer comments.
### 2. Workspace Setup
- **Worktree**: Create a new isolated worktree using
`agents/scripts/create_worktree.sh <cl_id>` for the CL to avoid polluting the
main workspace.
- **Checkout**: Patch the CL in the new worktree (e.g., `git cl patch X`).
- **Rebase**: Rebase the branch to `origin/main` to ensure it builds against the
latest code.
### 3. Reproduction & Triage
- **Reproduction**: Instruct the subagent to reproduce the failure locally
(e.g., run the failing test or compile target) to confirm the issue and
provide a baseline for verification.
- **Triage & Delegation**: Break down the identified errors or comments and
delegate them to subagents.
- **Track A (Fix/Address)**: Delegate the fixing of reported errors or
addressing specific reviewer comments to a `self` subagent with full tool
access.
- **Track B (Scan/Verify)**: Delegate a scan of other modified files or
running local tests to ensure no other issues were introduced.
### 4. Verification
- **Local Build/Test**: Instruct the subagent to verify that the fix compiles
locally and the reproduced failure is now resolved.
- **Upload**: Once verified locally, upload a new patchset using
`agents/scripts/upload_cl.sh cur check "<what you changed>"` to Gerrit to run
the remote checks or ask for re-review.
## Example: Fixing Errors
If the user says "fix errors on CL 12345":
1. Call `gerrit_cq` for CL 12345.
2. Identify that `v8_linux64_rel` failed with failing tests.
3. Create worktree `worktrees/cl-12345` and checkout CL.
4. **Spawn Subagent A to reproduce the failing tests locally.**
5. Spawn Subagent A to fix the failing tests.
6. Spawn Subagent B to check other modified files for potential issues.
7. Once Subagent A reports success and verification (tests pass), report to user
and ask if you should upload.
## Example: Addressing Comments
If the user says "address comments on CL 12345":
1. Call `gerrit_comments` for CL 12345.
2. Identify a comment requesting a refactor in `src/objects/lookup.cc`.
3. Create worktree `worktrees/cl-12345` and checkout CL.
4. Spawn Subagent A to perform the refactor as requested.
5. Spawn Subagent B to verify it compiles and run relevant unit tests.
6. Once Subagent A reports success, report to user and ask if you should upload.
deps/v8/agents/skills/workflow-perf/SKILL.md
Vendored
+167
View File
@@ -0,0 +1,167 @@
---
name: workflow-perf
description: Workflow for performance and memory evaluation in V8. Use when tasked with improving the performance or memory usage of a workload in V8. Do not use when debugging a crash or functionality issue.
---
# Workflow: Performance Evaluation
Use this skill when tasked with improving the performance or memory usage of a
workload in V8. This workflow focuses on identifying bottlenecks and applying
V8-side optimizations.
## Activation Criteria
- User requests to optimize a specific benchmark or script.
- Goal is to reduce execution time, CPU cycles, or memory footprint.
## Core Principles
1. **Data-Driven**: Always base optimization decisions on profiling data, not
intuition.
2. **V8-Centric**: For V8 engineers, performance work usually means changing V8
to better handle the JS pattern, rather than changing the JS itself (though
both are valid for general users).
3. **Holistic View**: Look for general efficiency improvements, not just the
single hottest function.
4. **Contextual Interpretation**: Assume unknown terms in performance tasks are
likely benchmark names or domain-specific concepts, not environmental terms
(e.g., "WSL" is likely a JetStream story, not the OS). Verify before
assuming. If in doubt, ask the user.
5. **Mandatory Orchestration**: The agent executing this workflow MUST act as an
Orchestrator. Delegate execution of benchmarks, profiles, or searches to
subagents to maximize parallelism.
6. **Local Experiment Baseline**: Whenever asked to perform a local experiment,
always compile the baseline first and store it in a separate directory like
`x64.release-baseline` for better `gm.py` integration. This avoids
recompiling at later stages.
## Workflow
### Planning
For performance analysis, you do NOT need to create a full
`implementation_plan.md` until you are actually _fixing_ the performance issue
you've detected. Instead, maintain an **Analysis Plan** (e.g., in `task.md` or
as a list of questions to answer) to guide the investigation.
### 1. Parallel Track Initialization
Initialize the following tracks concurrently:
- **Track A: Profiling & Tracing**:
- Run the workload with the v8-profiling skill (e.g. linux-perf and/or pprof).
- Use V8 tracing flags to gather specific runtime telemetry.
- **Track B: V8 Log Analysis**
- Use the v8-log skill to extract v8.log and analyze internal state of V8
- **Track C: JS Source Analysis**:
- Study the JavaScript benchmark to understand the core operations and
potential hotspots.
- **Benchmark Source Access**: If benchmark sources (such as JetStream 3) are
not locally available under `test/benchmarks/`, enable
`"checkout_benchmarks": True` in your `../.gclient` configuration
(`custom_vars`) and run `gclient sync`.
- **Track D: Static V8 Research**:
- Search for known optimization patterns or issues related to the observed JS
patterns in the V8 codebase.
### 3. Running Benchmarks / Pages in Chrome with with Crossbench
- **Generate Performance Logs and Profiles**: use the crossbench skill to gather
v8.log, detailed perfetto traces and sampling profiles from pages or
benchmarks.
- **Probes**:
- Use `--probe=profiling` for full-browser or d8 profiles
- Use `--probe=perfetto` for detailed perfetto traces
- Use `--probe=v8.log` for extracting internal v8 logs from chrome
### 4. Alternative: Running Benchmarks with jsb_run_bench
In the `jetski` environment, you can also use the `jsb_run_bench` tool from
`v8-utils` as an alternative for quick runs.
- **Run for Scores**: Call `jsb_run_bench` with paths to `d8` binaries to
compare performance.
- **Profile**: Supports `record: "perf"` and `record: "v8log"`.
### 5. Profile Analysis & Tick Processor
- **Generate and Analyze Profile**: Use the v8-profiling skill to generate and
analyze linux-perf and tickprocessor profiles. Note that you can use
crossbench for generating chromium-level profiles.
- **Cross Reference**:
- Correlate JS sources with v8.log to understand what V8 is doing when
executing the JS sources.
- Use the v8.log to further drill down on internal v8 state to understand
bottlenecks.
- **Interpretation**:
- Look at the C++ entry points and JS functions taking the most ticks.
- Check if time is spent in runtime functions vs. generated code.
- Identify if specific builtins are taking significant time.
- Identify inefficient JS code patterns in the workloads
- Suggest builtins, C++ code that can be optimized
### 6. Tracing Compiler Graphs (Turbolizer)
For peak performance, it is often necessary to inspect the intermediate
representations (IR) of the optimizing compiler (TurboFan or Turboshaft).
- **Generate Graph Data**: Run `d8 --trace-turbo script.js` or pass flags in
Crossbench/jsb_run_bench. This generates JSON files containing the graph state
at various optimization phases (e.g., `turbo-*.json`).
- **Visualize with Turbolizer**: Use the Turbolizer tool (available internally
at `go/turbolizer` or in the V8 repository under `tools/turbolizer`).
- **Analysis**:
- Inspect the graph at different phases to see how nodes are simplified,
combined, or eliminated.
- Look for missed optimizations, such as redundant checks that were not
hoisted or allocations that failed to be eliminated by escape analysis.
- Identify unexpected deoptimization points.
### 7. Identifying General Efficiency Improvements
Beyond hotspots, look for areas where V8 can be improved to handle patterns
better:
- **Reducing Allocations**: High GC overhead implies frequent allocations.
Investigate if V8 can optimize allocation folding, escape analysis, or if the
allocations are unavoidable.
- **Optimizing Hot Loops**: Ensure loops are not deoptimizing in V8. Check if
checks can be hoisted by the compiler or if loop peeling is effective in the
VM.
- **Hidden Class (Map) Stability**: Understand how object shapes evolve and
cause polymorphic or megamorphic IC states. Investigate if V8 can be optimized
to handle these transitions better.
### 8. Analysis & Reprioritization
- Analyze profile results (e.g., flamegraphs, top functions).
- **Dynamic Reprioritization**:
- **High GC Time**: If profile shows significant time in GC, pivot to
allocation analysis and reducing memory churn. Also explain which JS code is
causing frequent allocations.
- **High IC Misses**: If `--log-ic` shows frequent misses, pivot to
investigating object layout and stabilizing hidden classes.
- **Dominant Hotspot**: If a single function dominates execution time, focus
all efforts on that component.
- **Pattern Identification**: If a V8 change is identified that could improve
the pattern generally, prioritize implementing and testing it over further
analysis.
### 9. Optimization & Verification
- Propose a V8 change to improve performance (e.g., specialized builtin,
improved optimization pass).
- **Verification on Pinpoint (Preferred)**:
- Commit changes to a local branch.
- Use the automation script to upload a CL and start a Pinpoint job:
```bash
scripts/upload_and_pinpoint.py \
--benchmark=<benchmark_name> \
--bot=<bot_name> \
--message="Experiment: My performance optimization"
```
- Use `./cb.py pinpoint help` to understand the available options.
- **Local Verification**:
- Re-run the benchmark locally if Pinpoint is unavailable.
- Compare `perf` stats (cycles, instructions).
- Ensure no regressions in correctness or other benchmarks.
deps/v8/agents/skills/workflow-perf/scripts/upload_and_pinpoint.py
Vendored Executable
+73
View File
@@ -0,0 +1,73 @@
#!/usr/bin/env python3
# Copyright 2026 the V8 project authors. All rights reserved.
# Use of this source code is governed by a BSD-style license that can be
# found in the LICENSE file.
from __future__ import annotations
import argparse
import subprocess
import re
import sys
import shlex
from pathlib import Path
def run_command(cmd: list[str], cwd: str | None = None) -> str:
print(f"Running: {shlex.join(cmd)}")
result = subprocess.run(
cmd, cwd=cwd, capture_output=True, text=True, check=False)
if result.returncode != 0:
print(f"Error running command: {result.stderr}")
print(f"Stdout: {result.stdout}")
sys.exit(result.returncode)
return result.stdout
def main() -> None:
parser = argparse.ArgumentParser(
description="Upload CL and start Pinpoint job.")
parser.add_argument(
"--benchmark",
required=True,
help="Crossbench benchmark name (e.g., jetstream3.0.crossbench)")
parser.add_argument(
"--bot", required=True, help="Pinpoint bot name (e.g., linux-r350-perf)")
parser.add_argument(
"--message", required=True, help="Commit message for git cl upload")
home = Path.home()
parser.add_argument(
"--v8-dir", default=home / "v8", help="V8 repository directory")
parser.add_argument(
"--cb-dir", default=home / "crossbench", help="Crossbench directory")
args = parser.parse_args()
# 1. Upload CL
# Assumes changes are already committed on the current branch.
upload_cmd = ["./agents/scripts/upload_cl.sh", "cur", "nocheck", args.message]
stdout = run_command(upload_cmd, cwd=args.v8_dir)
print(stdout)
# 2. Extract CL URL
match = re.search(
r"https://chromium-review\.googlesource\.com/c/v8/v8/\+/\d+", stdout)
if not match:
print("Failed to find CL URL in git cl upload output.")
sys.exit(1)
cl_url = match.group(0)
print(f"Found CL URL: {cl_url}")
# 3. Start Pinpoint job
cb_cmd = [
"./cb.py", "pinpoint", "start", f"--benchmark={args.benchmark}",
f"--bot={args.bot}", f"--exp-patch={cl_url}"
]
cb_stdout = run_command(cb_cmd, cwd=args.cb_dir)
print(cb_stdout)
if __name__ == "__main__":
main()
deps/v8/bazel/config/BUILD.bazel
Vendored
+1
View File
@@ -82,6 +82,7 @@ config_setting(
v8_target_cpu(
name = "v8_target_cpu",
build_setting_default = "none",
scope = "universal",
)
config_setting(
deps/v8/bazel/config/v8-target-cpu.bzl
Vendored
+3
View File
@@ -26,6 +26,9 @@ v8_target_cpu = rule(
implementation = _host_target_cpu_impl,
build_setting = config.string(flag = True),
doc = "CPU that V8 will generate code for.",
attrs = {
"scope": attr.string(),
},
)
def v8_configure_target_cpu(name, matching_configs):
deps/v8/bazel/defs.bzl
Vendored
+19 -6
View File
@@ -20,28 +20,37 @@ def _options_impl(ctx):
_create_option_flag = rule(
implementation = _options_impl,
build_setting = config.bool(flag = True),
attrs = {
"scope": attr.string(),
},
)
_create_option_string = rule(
implementation = _options_impl,
build_setting = config.string(flag = True),
attrs = {
"scope": attr.string(),
},
)
_create_option_int = rule(
implementation = _options_impl,
build_setting = config.int(flag = True),
attrs = {
"scope": attr.string(),
},
)
def v8_flag(name, default = False):
_create_option_flag(name = name, build_setting_default = default)
_create_option_flag(name = name, build_setting_default = default, scope = "universal")
native.config_setting(name = "is_" + name, flag_values = {name: "True"})
native.config_setting(name = "is_not_" + name, flag_values = {name: "False"})
def v8_string(name, default = ""):
_create_option_string(name = name, build_setting_default = default)
_create_option_string(name = name, build_setting_default = default, scope = "universal")
def v8_int(name, default = 0):
_create_option_int(name = name, build_setting_default = default)
_create_option_int(name = name, build_setting_default = default, scope = "universal")
def _custom_config_impl(ctx):
defs = []
@@ -123,7 +132,6 @@ def _default_args():
"-Wno-implicit-int-float-conversion",
"-Wno-deprecated-copy",
"-Wno-non-virtual-dtor",
"-Wno-unnecessary-virtual-specifier",
"-isystem .",
],
"//conditions:default": [],
@@ -352,8 +360,6 @@ def _torque_files_impl(ctx):
if root[:len(v8root)] == v8root:
root = root[len(v8root):]
file = ctx.attr.prefix + "/torque-generated/" + root
defs.append(ctx.actions.declare_file(file + "-tq-inl.inc"))
defs.append(ctx.actions.declare_file(file + "-tq.inc"))
defs.append(ctx.actions.declare_file(file + "-tq.cc"))
inits.append(ctx.actions.declare_file(file + "-tq-csa.cc"))
inits.append(ctx.actions.declare_file(file + "-tq-csa.h"))
@@ -467,6 +473,7 @@ def _mksnapshot(ctx):
ctx.actions.run(
outputs = outs,
inputs = [],
mnemonic = "V8Mksnapshot",
arguments = [
"--embedded_variant=Default",
"--target_os",
@@ -564,9 +571,11 @@ def build_config_content(cpu, icu):
("dict_property_const_tracking", "false"),
("direct_handle", "false"),
("disassembler", "false"),
("dumpling", "false"),
("full_debug", "false"),
("gdbjit", "false"),
("has_jitless", "false"),
("sparkplug_plus", "true" if cpu in ['"x64"', '"arm64"'] else "false"),
("has_maglev", "true"),
("has_turbofan", "true"),
("has_webassembly", "false"),
@@ -574,12 +583,14 @@ def build_config_content(cpu, icu):
("i18n", icu),
("is_android", "false"),
("is_ios", "false"),
("is_linux", "true"),
("js_shared_memory", "false"),
("leaptiering", "true"),
("lite_mode", "false"),
("local_off_stack_check", "false"),
("lower_limits_mode", "false"),
("memory_corruption_api", "false"),
("cppgc_microtask_queue", "false"),
("mips_arch_variant", '""'),
("mips_use_msa", "false"),
("msan", "false"),
@@ -595,6 +606,7 @@ def build_config_content(cpu, icu):
("single_generation", "false"),
("slow_dchecks", "false"),
("target_cpu", cpu),
("temporal", "false"),
("tsan", "false"),
("ubsan", "false"),
("use_sanitizer", "false"),
@@ -605,6 +617,7 @@ def build_config_content(cpu, icu):
("verify_heap", "false"),
("verify_predictable", "false"),
("wasm_random_fuzzers", "false"),
("test_only_sync_points", "false"),
("write_barriers", "false"),
])
deps/v8/bazel/patches/BUILD.bazel
Vendored
+1
View File
@@ -0,0 +1 @@
exports_files(["highway_rules_cc.patch"])
Loaded 100 of 7949 files, more files were not shown because too many files have changed in this diff. Show more