v8/test/cctest/BUILD.gn

524 lines
15 KiB
Plaintext
Raw Normal View History

# Copyright 2016 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.
import("../../gni/v8.gni")
config("cctest_config") {
# Work around a bug in the gold linker.
if (use_gold && target_cpu == "x86") {
ldflags = [ "-Wl,--icf=none" ]
}
}
v8_executable("cctest") {
testonly = true
sources = [ "cctest.cc" ]
deps = [ ":cctest_sources" ]
data_deps = [ "../../tools:v8_testrunner" ]
data = [
"testcfg.py",
"cctest.status",
"interpreter/bytecode_expectations/",
]
configs = [
"../..:external_config",
"../..:internal_config_base",
"../..:v8_tracing_config",
":cctest_config",
]
ldflags = []
if (v8_use_perfetto) {
deps += [
# TODO(skyostil): Switch the test to use protozero.
"//third_party/perfetto/protos/perfetto/trace/interned_data:lite",
"//third_party/perfetto/protos/perfetto/trace/track_event:lite",
]
}
if (current_os == "aix") {
ldflags = [ "-Wl,-bbigtoc" ]
}
}
v8_header_set("cctest_headers") {
testonly = true
configs = [
"../..:external_config",
"../..:internal_config_base",
]
deps = [
"../..:v8_internal_headers",
"../..:v8_libbase",
"../..:v8_libplatform",
]
sources = [ "cctest.h" ]
}
config("cctest_sources_config") {
if (is_clang) {
cflags = [ "-Wno-string-concatenation" ]
}
}
v8_source_set("cctest_sources") {
testonly = true
sources = [
### gcmole(all) ###
Reland "[turboassembler] Introduce hard-abort mode" This is a reland of a462a7854a081f4f34bb4c112ee33f3d69efa309 Original change's description: > [turboassembler] Introduce hard-abort mode > > For checks and assertions (mostly for debug code, like stack alignment > or zero extension), we had two modes: Emit a call to the {Abort} > runtime function (the default), and emit a debug break (used for > testing, enabled via --trap-on-abort). > In wasm, where we cannot just call a runtime function because code must > be isolate independent, we always used the trap-on-abort behaviour. > This causes problems for our fuzzers, which do not catch SIGTRAP, and > hence do not detect debug code failures. > > This CL introduces a third mode ("hard abort"), which calls a C > function via {ExternalReference}. The C function still outputs the > abort reason, but does not print the stack trace. It then aborts via > "OS::Abort", just like the runtime function. > This will allow fuzzers to detect the crash and even find a nice error > message. > > Even though this looks like a lot of code churn, it is actually not. > Most added lines are new tests, and other changes are minimal. > > R=mstarzinger@chromium.org > > Bug: chromium:863799 > Change-Id: I77c58ff72db552d49014614436259ccfb49ba87b > Reviewed-on: https://chromium-review.googlesource.com/1142163 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#54592} Bug: chromium:863799 Change-Id: I7729a47b4823a982a8e201df36520aa2b6ef5326 Reviewed-on: https://chromium-review.googlesource.com/1146100 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54656}
2018-07-24 14:12:47 +00:00
"../common/assembler-tester.h",
"../common/flag-utils.h",
Reland^2 "[csa] Fix semantics of PopAndReturn" This is a reland of 3593ee832c14cf9421c11b5504097169ff25522b The MSAN doesn't seem to be considering initializing stores via inline assembly as such (in a new cctest helper GetStackPointer()), so this reland attempt fixes the issue and ensures that the MSAN bot is happy. Original change's description: > Reland "[csa] Fix semantics of PopAndReturn" > > This is a reland of 5e5eaf7954bbf490647498ca3eaa4e1736792789 > > This CL fixes the "function returns address of local variable" issue > which GCC was complaining about by using inline assembly instead of > address of a local for getting stack pointer approximation. > > Original change's description: > > [csa] Fix semantics of PopAndReturn > > > > This CL prohibits using PopAndReturn from the builtins that > > have calling convention with arguments on the stack. > > > > This CL also updates the PopAndReturn tests so that even off-by-one > > errors in the number of poped arguments are caught which was not the > > case before. > > > > Motivation: > > > > PopAndReturn is supposed to be using ONLY in CSA/Torque builtins for > > dropping ALL JS arguments that are currently located on the stack. > > Disallowing PopAndReturn in builtins with stack arguments simplifies > > semantics of this instruction because in case of presence of declared > > stack parameters it's impossible to distinguish the following cases: > > 1) stack parameter is included in JS arguments (and therefore it will > > be dropped as a part of 'pop' number of arguments), > > 2) stack parameter is NOT included in JS arguments (and therefore it > > should be dropped in ADDITION to the 'pop' number of arguments). > > > > This issue wasn't noticed before because builtins with stack parameters > > relied on adapter frames machinery to ensure that the expected > > parameters are present on the stack, but on the same time the adapter > > frame tearing down code was effectively recovering the stack pointer > > potentially broken by the CSA builtin. > > > > Once we get rid of the arguments adapter frames keeping stack pointer > > in a valid state becomes crucial. > > > > Bug: v8:5269, v8:10201 > > Change-Id: Id3ea9730bb0d41d17999c73136c4dfada374a822 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460819 > > Commit-Queue: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#70454} > > Tbr: tebbi@chromium.org > Bug: v8:5269 > Bug: v8:10201 > Change-Id: Ic1a05fcc4efd2068538bff28189545cfd2617d9b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465839 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70483} Tbr: tebbi@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng Bug: v8:5269 Bug: v8:10201 Change-Id: Ib09af2d1260bb42ac26aabface14e6b83b3efec4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2467847 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70492}
2020-10-13 15:44:09 +00:00
"cctest-utils.h",
"collector.h",
"compiler/c-signature.h",
"compiler/call-tester.h",
"compiler/code-assembler-tester.h",
"compiler/function-tester.cc",
"compiler/function-tester.h",
"compiler/node-observer-tester.h",
"compiler/test-atomic-load-store-codegen.cc",
"compiler/test-basic-block-profiler.cc",
"compiler/test-branch-combine.cc",
"compiler/test-calls-with-arraylike-or-spread.cc",
"compiler/test-code-assembler.cc",
Reland "[arm] Restrict grouping pushes before a TailCall to registers only" This is a reland of a72b2f88a8cb44f12002f1168c639e07db9d5600 Original change's description: > [arm] Restrict grouping pushes before a TailCall to registers only > > We optimize parallel moves performed before a TailCall by grouping adjacent > pushes. This way, we may use a single instruction to push multiple registers at > once. However, we also have support for pushing immediates and stack slots for > which the benefit is questionnable therefore this patch removes support for > them. > > Concerning immediate pushes, it looks like a mistake since we do not have > support for this case in `AssembleMove` so this patch removes it. Furthermore, > if we add a test for this case, we see that a `push ip` instruction is > generated, effectively pushing whatever was in `ip` at the time instead of > pushing a constant. > > Concerning stack slot pushes, we generate a more or less equivalent sequence of > instructions. > > Finally, grouping floating point pushes is not used anywhere so this patch > removes support for this also. > > Bug: v8:6553 > Change-Id: I9b820d33361fc442dd813f66e1f96cda41009110 > Reviewed-on: https://chromium-review.googlesource.com/567191 > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > Cr-Commit-Position: refs/heads/master@{#46718} Bug: v8:6553 Change-Id: Ib9a55dae7cc5db6185d163c56088ff23426d04bb Reviewed-on: https://chromium-review.googlesource.com/576087 Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#46754}
2017-07-13 09:55:16 +00:00
"compiler/test-code-generator.cc",
"compiler/test-codegen.cc",
"compiler/test-codegen.h",
"compiler/test-concurrent-shared-function-info.cc",
"compiler/test-gap-resolver.cc",
"compiler/test-graph-visualizer.cc",
"compiler/test-instruction-scheduler.cc",
"compiler/test-instruction.cc",
"compiler/test-js-constant-cache.cc",
"compiler/test-js-context-specialization.cc",
"compiler/test-js-typed-lowering.cc",
"compiler/test-jump-threading.cc",
"compiler/test-linkage.cc",
"compiler/test-loop-analysis.cc",
"compiler/test-machine-operator-reducer.cc",
"compiler/test-node.cc",
"compiler/test-operator.cc",
"compiler/test-representation-change.cc",
"compiler/test-run-bytecode-graph-builder.cc",
"compiler/test-run-calls-to-external-references.cc",
"compiler/test-run-deopt.cc",
"compiler/test-run-jsbranches.cc",
"compiler/test-run-jscalls.cc",
"compiler/test-run-jsexceptions.cc",
"compiler/test-run-jsobjects.cc",
"compiler/test-run-jsops.cc",
"compiler/test-run-load-store.cc",
"compiler/test-run-machops.cc",
"compiler/test-run-stackcheck.cc",
Reland "[arm64] Preparation for padding of arguments" This is a reland of bcf1172992a2d817978ff19a2d814c7629443956 The test was timing out in no snapshot builds, as each CodeAssemblerTester creates a new Context. Reduced the random iterations significantly. Original change's description: > [arm64] Preparation for padding of arguments > > As part of JSSP removal, we need to align the arguments passed to functions > on the stack, by adding a padding slot when the total number of arguments > is odd. > > This patch introduces the kPadArguments flag (which is currently set to > false for all architectures), which will control padding of arguments in > architecture-independent parts of the code (deoptimizer, instruction > selector). > > It also adds some executable tests for tail calls with various stack > parameter counts on the caller and callee sides. > > This will be turned on for arm64 together with arm64-specific changes to > the code generator, the MacroAsembler and the builtins, in a later patch. > > Bug: v8:6644 > Change-Id: I79a5c149123fe8130cedd1ccffec3d9b50361e08 > Reviewed-on: https://chromium-review.googlesource.com/806554 > Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#50134} TBR=jarin@chromium.org Bug: v8:6644 Change-Id: I795877ed9791e126ffac6841dbbb65189e95d207 Reviewed-on: https://chromium-review.googlesource.com/833046 Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#50238}
2017-12-18 18:55:23 +00:00
"compiler/test-run-tail-calls.cc",
"compiler/test-run-unwinding-info.cc",
"compiler/test-run-variables.cc",
"compiler/test-sloppy-equality.cc",
"compiler/test-verify-type.cc",
"compiler/value-helper.cc",
"compiler/value-helper.h",
"expression-type-collector-macros.h",
"gay-fixed.cc",
"gay-fixed.h",
"gay-precision.cc",
"gay-precision.h",
"gay-shortest.cc",
"gay-shortest.h",
"heap/heap-tester.h",
"heap/heap-utils.cc",
"heap/heap-utils.h",
"heap/test-alloc.cc",
"heap/test-array-buffer-tracker.cc",
"heap/test-compaction.cc",
"heap/test-concurrent-allocation.cc",
"heap/test-concurrent-marking.cc",
"heap/test-external-string-tracker.cc",
"heap/test-heap.cc",
"heap/test-incremental-marking.cc",
"heap/test-invalidated-slots.cc",
Reland "[heap] Skip ro-space from heap iterators, add CombinedHeapIterator." Code relocation info is now always allocated in old-space. Before relocation info allocated for placeholders and builtins (which get replaced with trampolines in nosnap builds) would become unreachable. Since read-only space is not GCed and ReadOnlyHeapIterator doesn't check for reachability, ValidateSnapshot would fail finding unreachable objects returned by ReadOnlyHeapIterator. Because trampoline relocation info gets replaced with canonical one, this only affects no-embdded-builtins nosnap builds, which don't get much benefit from read-only relocation info anyway. A new check has been added to the read-only deserializer to verify that every read-only object is reachable at mksnapshot-time. The CombinedHeapIterator iteration order was changed to iterate over read-only space first, because that's how HeapIterator worked. This is a reland of 3d1d8eae772877422e7082571e77c326e7e8e60a Original change's description: > [heap] Skip ro-space from heap iterators, add CombinedHeapIterator. > > Read-only space sharing requires an iterator independent of heap. This > also enables future removal of read-only space from heap. > > Bug: v8:7464 > Change-Id: Ia07a9369494ea2c547d12c01ffa1d7b8b6bbeabc > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552795 > Commit-Queue: Maciej Goszczycki <goszczycki@google.com> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#60819} Bug: v8:7464 Change-Id: I49ae070955b77956962334a84f762ab29052d5ff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1566513 Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Maciej Goszczycki <goszczycki@google.com> Cr-Commit-Position: refs/heads/master@{#61185}
2019-05-02 15:35:51 +00:00
"heap/test-iterators.cc",
"heap/test-mark-compact.cc",
"heap/test-memory-measurement.cc",
"heap/test-page-promotion.cc",
"heap/test-shared-heap.cc",
"heap/test-spaces.cc",
"heap/test-unmapper.cc",
"heap/test-weak-references.cc",
"heap/test-write-barrier.cc",
"interpreter/bytecode-expectations-printer.cc",
"interpreter/bytecode-expectations-printer.h",
"interpreter/interpreter-tester.cc",
"interpreter/interpreter-tester.h",
"interpreter/source-position-matcher.cc",
"interpreter/source-position-matcher.h",
"interpreter/test-bytecode-generator.cc",
"interpreter/test-interpreter-intrinsics.cc",
"interpreter/test-interpreter.cc",
"interpreter/test-source-positions.cc",
"libplatform/test-tracing.cc",
"libsampler/test-sampler.cc",
"libsampler/test-signals-and-mutexes.cc",
Reland x6 [arraybuffer] Rearchitect backing store ownership This reverts commit 9da3483136b5e71e830ed9a9c34802ad8d605e58 Original change's description: > "Reland x4 [arraybuffer] Rearchitect backing store ownership" > > This is a reland of bc33f5aeba9ceb13f8bfc401c5ba2521c2207ffb > > Contributed by titzer@chromium.org > > Original change's description: > > [arraybuffer] Rearchitect backing store ownership > > > > This CL completely rearchitects the ownership of array buffer backing stores, > > consolidating ownership into a {BackingStore} C++ object that is tracked > > throughout V8 using unique_ptr and shared_ptr where appropriate. > > > > Overall, lifetime management is simpler and more explicit. The numerous > > ways that array buffers were initialized have been streamlined to one > > Attach() method on JSArrayBuffer. The array buffer tracker in the > > GC implementation now manages std::shared_ptr<BackingStore> pointers, > > and the construction and destruction of the BackingStore object itself > > handles the underlying page or embedder-allocated memory. > > > > The embedder API remains unchanged for now. We use the > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to > > keep the backing store alive properly, even in the case of aliases > > from live heap objects. Thus the embedder has a lower chance of making > > a mistake. Long-term, we should move the embedder to a model where they > > manage backing stores using shared_ptr to an opaque backing store object. > > TBR=yangguo@chromium.org > > BUG=v8:9380,v8:9221,chromium:986318 > > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005 > Commit-Queue: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63041} TBR=yangguo@chromium.org Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#63617}
2019-09-09 10:19:34 +00:00
"manually-externalized-buffer.h",
"parsing/test-parse-decision.cc",
"parsing/test-preparser.cc",
"parsing/test-scanner-streams.cc",
"parsing/test-scanner.cc",
"print-extension.cc",
"print-extension.h",
"profiler-extension.cc",
"profiler-extension.h",
"scope-test-helper.h",
"setup-isolate-for-tests.cc",
"setup-isolate-for-tests.h",
"test-access-checks.cc",
"test-accessor-assembler.cc",
"test-accessors.cc",
"test-allocation.cc",
"test-api-accessors.cc",
"test-api-array-buffer.cc",
"test-api-icu.cc",
"test-api-interceptors.cc",
"test-api-stack-traces.cc",
"test-api-typed-array.cc",
"test-api.cc",
"test-api.h",
"test-atomicops.cc",
"test-bignum-dtoa.cc",
"test-code-stub-assembler.cc",
"test-constantpool.cc",
"test-cpu-profiler.cc",
Reland "Add postmortem debugging helper library" This is a reland of 517ab73fd7e3fdb70220b9699bca4c69a32e212e Updates since original: now compressed pointers passed to the function GetObjectProperties are required to be sign-extended. Previously, the function allowed zero-extended values, but that led to ambiguity on pointers like 0x88044919: is it compressed or is the heap range actually centered on 0x100000000? Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} Bug: v8:9376 Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
2019-07-30 14:38:15 +00:00
"test-debug-helper.cc",
"test-debug.cc",
"test-decls.cc",
"test-deoptimization.cc",
"test-descriptor-array.cc",
"test-dictionary.cc",
"test-disasm-regex-helper.cc",
"test-disasm-regex-helper.h",
"test-diy-fp.cc",
"test-double.cc",
"test-dtoa.cc",
"test-elements-kind.cc",
"test-factory.cc",
"test-fast-dtoa.cc",
"test-feedback-vector.cc",
"test-feedback-vector.h",
"test-field-type-tracking.cc",
"test-fixed-dtoa.cc",
"test-flags.cc",
"test-func-name-inference.cc",
"test-global-handles.cc",
"test-global-object.cc",
"test-hashcode.cc",
"test-hashmap.cc",
"test-heap-profiler.cc",
"test-icache.cc",
"test-identity-map.cc",
"test-ignition-statistics-extension.cc",
"test-inobject-slack-tracking.cc",
"test-inspector.cc",
"test-intl.cc",
"test-js-weak-refs.cc",
"test-liveedit.cc",
"test-local-handles.cc",
"test-lockers.cc",
"test-log.cc",
"test-managed.cc",
"test-mementos.cc",
"test-orderedhashtable.cc",
"test-parsing.cc",
"test-persistent-handles.cc",
"test-platform.cc",
"test-profile-generator.cc",
"test-property-details.cc",
"test-ptr-compr-cage.cc",
"test-random-number-generator.cc",
"test-representation.cc",
"test-roots.cc",
"test-sampler-api.cc",
"test-serialize.cc",
"test-shared-strings.cc",
"test-smi-lexicographic-compare.cc",
"test-strings.cc",
"test-strtod.cc",
"test-swiss-name-dictionary-csa.cc",
"test-swiss-name-dictionary-infra.cc",
"test-swiss-name-dictionary.cc",
"test-symbols.cc",
"test-temporal-parser.cc",
"test-thread-termination.cc",
"test-threads.cc",
"test-trace-event.cc",
"test-traced-value.cc",
"test-transitions.cc",
"test-transitions.h",
"test-typedarrays.cc",
"test-types.cc",
"test-unscopables-hidden-prototype.cc",
"test-unwinder-code-pages.cc",
"test-usecounters.cc",
"test-utils.cc",
"test-verifiers.cc",
"test-version.cc",
"test-weakmaps.cc",
"test-weaksets.cc",
"test-web-snapshots.cc",
"torque/test-torque.cc",
"trace-extension.cc",
"trace-extension.h",
"unicode-helpers.cc",
"unicode-helpers.h",
]
if (v8_current_cpu == "arm") {
sources += [ ### gcmole(arch:arm) ###
Revert "Revert "[cctest] Clarify that tests for sync instructions are simulator specific"" This reverts commit 1feadfe81b7cc250df83cbf0b2fdfd17ac348cf8. Reason for revert: Reland as bot stayed red after revert. Original change's description: > Revert "[cctest] Clarify that tests for sync instructions are simulator specific" > > This reverts commit 4013518fe3be92f0fbd043b09017f5eb8b8629d8. > > Reason for revert: > https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress > > Original change's description: > > [cctest] Clarify that tests for sync instructions are simulator specific > > > > Some tests were recently added to test-simulator-arm.cc, however this file is > > meant for tests that are specific to the simulator and therefore are not written > > to work on hardware. While this sounds surprising, the reason is that our simulation > > of synchronisation instructions is more conservative than on hardware. > > > > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc" > > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests > > into "test-assembler-arm.cc" which is were tests that are garanteed to work in > > either native or simulated environments live. > > > > Finally, take the opportunity to share a little bit of code. > > > > Bug: v8:6963 > > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c > > Reviewed-on: https://chromium-review.googlesource.com/749387 > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > > Cr-Commit-Position: refs/heads/master@{#49073} > > TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org > > Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:6963 > Reviewed-on: https://chromium-review.googlesource.com/750624 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49074} TBR=machenbach@chromium.org,clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org Change-Id: I5af7bd3678758130534730a2f6f0b651b64c6956 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6963 Reviewed-on: https://chromium-review.googlesource.com/750903 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49075}
2017-11-02 13:11:29 +00:00
"assembler-helper-arm.cc",
"assembler-helper-arm.h",
"test-assembler-arm.cc",
"test-disasm-arm.cc",
"test-macro-assembler-arm.cc",
Revert "Revert "[cctest] Clarify that tests for sync instructions are simulator specific"" This reverts commit 1feadfe81b7cc250df83cbf0b2fdfd17ac348cf8. Reason for revert: Reland as bot stayed red after revert. Original change's description: > Revert "[cctest] Clarify that tests for sync instructions are simulator specific" > > This reverts commit 4013518fe3be92f0fbd043b09017f5eb8b8629d8. > > Reason for revert: > https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress > > Original change's description: > > [cctest] Clarify that tests for sync instructions are simulator specific > > > > Some tests were recently added to test-simulator-arm.cc, however this file is > > meant for tests that are specific to the simulator and therefore are not written > > to work on hardware. While this sounds surprising, the reason is that our simulation > > of synchronisation instructions is more conservative than on hardware. > > > > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc" > > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests > > into "test-assembler-arm.cc" which is were tests that are garanteed to work in > > either native or simulated environments live. > > > > Finally, take the opportunity to share a little bit of code. > > > > Bug: v8:6963 > > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c > > Reviewed-on: https://chromium-review.googlesource.com/749387 > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > > Cr-Commit-Position: refs/heads/master@{#49073} > > TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org > > Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:6963 > Reviewed-on: https://chromium-review.googlesource.com/750624 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49074} TBR=machenbach@chromium.org,clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org Change-Id: I5af7bd3678758130534730a2f6f0b651b64c6956 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6963 Reviewed-on: https://chromium-review.googlesource.com/750903 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49075}
2017-11-02 13:11:29 +00:00
"test-sync-primitives-arm.cc",
]
} else if (v8_current_cpu == "arm64") {
sources += [ ### gcmole(arch:arm64) ###
"test-assembler-arm64.cc",
"test-disasm-arm64.cc",
"test-fuzz-arm64.cc",
"test-javascript-arm64.cc",
"test-js-arm64-variables.cc",
"test-macro-assembler-arm64.cc",
"test-pointer-auth-arm64.cc",
Revert "Revert "[cctest] Clarify that tests for sync instructions are simulator specific"" This reverts commit 1feadfe81b7cc250df83cbf0b2fdfd17ac348cf8. Reason for revert: Reland as bot stayed red after revert. Original change's description: > Revert "[cctest] Clarify that tests for sync instructions are simulator specific" > > This reverts commit 4013518fe3be92f0fbd043b09017f5eb8b8629d8. > > Reason for revert: > https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress > > Original change's description: > > [cctest] Clarify that tests for sync instructions are simulator specific > > > > Some tests were recently added to test-simulator-arm.cc, however this file is > > meant for tests that are specific to the simulator and therefore are not written > > to work on hardware. While this sounds surprising, the reason is that our simulation > > of synchronisation instructions is more conservative than on hardware. > > > > To make this more clear, this patch renames the "test-simulator-arm{,64}.cc" > > files to "test-sync-primitives-arm{,64}.cc", and moves the vneg and vabs tests > > into "test-assembler-arm.cc" which is were tests that are garanteed to work in > > either native or simulated environments live. > > > > Finally, take the opportunity to share a little bit of code. > > > > Bug: v8:6963 > > Change-Id: Ifb85d3671c823b9bba73d09f419536b089a4e87c > > Reviewed-on: https://chromium-review.googlesource.com/749387 > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > > Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> > > Cr-Commit-Position: refs/heads/master@{#49073} > > TBR=clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org > > Change-Id: I1bfb4e9c7c18b716f417a84b18a14cb2e1fa3a7a > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: v8:6963 > Reviewed-on: https://chromium-review.googlesource.com/750624 > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49074} TBR=machenbach@chromium.org,clemensh@chromium.org,pierre.langlois@arm.com,bmeurer@chromium.org Change-Id: I5af7bd3678758130534730a2f6f0b651b64c6956 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6963 Reviewed-on: https://chromium-review.googlesource.com/750903 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#49075}
2017-11-02 13:11:29 +00:00
"test-sync-primitives-arm64.cc",
"test-utils-arm64.cc",
"test-utils-arm64.h",
]
Unwind V8 frames correctly on Windows ARM64 On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
2019-07-27 06:36:52 +00:00
if (is_win) {
sources += [ "test-stack-unwinding-win64.cc" ]
}
} else if (v8_current_cpu == "x86") {
sources += [ ### gcmole(arch:ia32) ###
"test-assembler-ia32.cc",
"test-disasm-ia32.cc",
"test-log-stack-tracer.cc",
]
} else if (v8_current_cpu == "mips") {
sources += [ ### gcmole(arch:mips) ###
"test-assembler-mips.cc",
"test-disasm-mips.cc",
"test-macro-assembler-mips.cc",
]
} else if (v8_current_cpu == "mipsel") {
sources += [ ### gcmole(arch:mipsel) ###
"test-assembler-mips.cc",
"test-disasm-mips.cc",
"test-macro-assembler-mips.cc",
]
} else if (v8_current_cpu == "mips64") {
sources += [ ### gcmole(arch:mips64) ###
"test-assembler-mips64.cc",
"test-disasm-mips64.cc",
"test-macro-assembler-mips64.cc",
]
} else if (v8_current_cpu == "mips64el") {
sources += [ ### gcmole(arch:mips64el) ###
"test-assembler-mips64.cc",
"test-disasm-mips64.cc",
"test-macro-assembler-mips64.cc",
]
} else if (v8_current_cpu == "x64") {
sources += [ ### gcmole(arch:x64) ###
"test-assembler-x64.cc",
"test-disasm-x64.cc",
"test-log-stack-tracer.cc",
"test-macro-assembler-x64.cc",
]
Reland "V8 x64 backend doesn't emit ABI compliant stack frames" This is a reland of 3cda21de77d098a612eadf44d504b188a599c5f0 Original change's description: > V8 x64 backend doesn't emit ABI compliant stack frames > > On 64 bit Windows, the OS stack walking does not work because the V8 x64 > backend doesn't emit unwinding info and also because it doesn't emit ABI > compliant stack frames. See > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit > for more details. > > This problem can be fixed by observing that V8 frames usually all have the same > prolog and epilog: > > push rbp, > mov rbp, rsp > ... > pop rbp > ret N > > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows > should walk through V8 frames. Furthermore, since V8 Code objects are all > allocated in the same code-range for an Isolate, it is possible to register a > single PDATA/XDATA entry to cover stack walking for all the code generated > inside that code-range. > > This PR contains changes required to enable stack walking on Win64: > > EmbeddedFileWriter now adds assembler directives to the builtins > snapshot source file (embedded.cc) to emit additional entries in the .pdata and > in the .xdata section of the V8 executable. This takes care of stack walking > for embedded builtins. (The case of non-embedded builtins is not supported). > The x64 Assembler has been modified to collect the information required to emit > this unwind info for builtins. > > Stack walking for jitted code is handled is Isolate.cpp, by registering > dynamically PDATA/XDATA for the whole code-range address space every time a new > Isolate is initialized, and by unregistering them when the Isolate is > destroyed. > > Stack walking for WASM jitted code is handled is the same way in > wasm::NativeModule (wasm/wasm-code-manager.cpp). > > It is important to note that Crashpad and Breakpad are already registering > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded > builtins). Since it is not possible to register multiple PDATA entries for the > same address range, a new function is added to the V8 API: > SetUnhandledExceptionCallback() can be used by an embedder to register its own > unhandled exception handler for exceptions that arise in v8-generated code. > V8 embedders should be modified accordingly (code for this is in a separate PR > in the Chromium repository: > https://chromium-review.googlesource.com/c/chromium/src/+/1474703). > > All these changes are experimental, behind: > > the 'v8_win64_unwinding_info' build flag, and > the '--win64-unwinding-info' runtime flag. > > Bug: v8:3598 > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#60330} Bug: v8:3598 Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60581}
2019-04-01 21:43:23 +00:00
if (is_win) {
Unwind V8 frames correctly on Windows ARM64 On Windows ARM64, OS stack walking does not work because the V8 ARM64 backend doesn't emit unwinding info and also because it doesn't emit ABI compliant stack frames. This was fixed for Windows X64 (https://crrev.com/c/1469329) and documented below: https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0 This problem can be fixed similarly for Windows ARM64 by observing that V8 frames usually all have the same prolog which maintains a chain via frame pointer (fp or x29 register). stp fp, lr, [sp, ...] One exception is JSEntry which stops fp pointer chain and needs to be handled specially. So it is possible to define XDATA with UNWIND_CODE which specify how Windows should walk through V8 dynamic frames. The same as X64, since V8 Code objects are all allocated in the same code-range for an Isolate, it is possible to register at most 2 XDATA and a group of PDATA entries to cover stack walking for all the code generated inside that code-range. This is more than 1 PDATA/XDATA because according to the Windows ARM64 exeption handling document, 1 PDATA can cover less than 1MB code range (see below doc). https://docs.microsoft.com/en-us/cpp/build/arm64-exception-handling This PR implements stackwalk for Windows ARM64 to be on par with X64, including embedded builtins, jitted code and wasm jitted code, but not including register handler for handling exception only, because there is no backward compatibility to maintain for Windows ARM64 which was released since 1709 windows build. Bug: chromium:893460 Change-Id: Ic74cbdad8af5cf342185030a4c53796f12ea5429 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701133 Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63002}
2019-07-27 06:36:52 +00:00
sources += [ "test-stack-unwinding-win64.cc" ]
Reland "V8 x64 backend doesn't emit ABI compliant stack frames" This is a reland of 3cda21de77d098a612eadf44d504b188a599c5f0 Original change's description: > V8 x64 backend doesn't emit ABI compliant stack frames > > On 64 bit Windows, the OS stack walking does not work because the V8 x64 > backend doesn't emit unwinding info and also because it doesn't emit ABI > compliant stack frames. See > https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit > for more details. > > This problem can be fixed by observing that V8 frames usually all have the same > prolog and epilog: > > push rbp, > mov rbp, rsp > ... > pop rbp > ret N > > and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows > should walk through V8 frames. Furthermore, since V8 Code objects are all > allocated in the same code-range for an Isolate, it is possible to register a > single PDATA/XDATA entry to cover stack walking for all the code generated > inside that code-range. > > This PR contains changes required to enable stack walking on Win64: > > EmbeddedFileWriter now adds assembler directives to the builtins > snapshot source file (embedded.cc) to emit additional entries in the .pdata and > in the .xdata section of the V8 executable. This takes care of stack walking > for embedded builtins. (The case of non-embedded builtins is not supported). > The x64 Assembler has been modified to collect the information required to emit > this unwind info for builtins. > > Stack walking for jitted code is handled is Isolate.cpp, by registering > dynamically PDATA/XDATA for the whole code-range address space every time a new > Isolate is initialized, and by unregistering them when the Isolate is > destroyed. > > Stack walking for WASM jitted code is handled is the same way in > wasm::NativeModule (wasm/wasm-code-manager.cpp). > > It is important to note that Crashpad and Breakpad are already registering > PDATA/XDATA to manage and report unhandled exceptions (but not for embedded > builtins). Since it is not possible to register multiple PDATA entries for the > same address range, a new function is added to the V8 API: > SetUnhandledExceptionCallback() can be used by an embedder to register its own > unhandled exception handler for exceptions that arise in v8-generated code. > V8 embedders should be modified accordingly (code for this is in a separate PR > in the Chromium repository: > https://chromium-review.googlesource.com/c/chromium/src/+/1474703). > > All these changes are experimental, behind: > > the 'v8_win64_unwinding_info' build flag, and > the '--win64-unwinding-info' runtime flag. > > Bug: v8:3598 > Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329 > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Paolo Severini <paolosev@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#60330} Bug: v8:3598 Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618 Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Paolo Severini <paolosev@microsoft.com> Cr-Commit-Position: refs/heads/master@{#60581}
2019-04-01 21:43:23 +00:00
}
} else if (v8_current_cpu == "ppc" || v8_current_cpu == "ppc64") {
sources += [ ### gcmole(arch:ppc) ###
"test-assembler-ppc.cc",
"test-disasm-ppc.cc",
]
} else if (v8_current_cpu == "s390" || v8_current_cpu == "s390x") {
sources += [ ### gcmole(arch:s390) ###
"test-assembler-s390.cc",
"test-disasm-s390.cc",
]
} else if (v8_current_cpu == "riscv64") {
sources += [ ### gcmole(arch:riscv64) ###
"test-assembler-riscv64.cc",
"test-disasm-riscv64.cc",
"test-helper-riscv64.cc",
"test-macro-assembler-riscv64.cc",
"test-simple-riscv64.cc",
]
} else if (v8_current_cpu == "loong64") {
sources += [ ### gcmole(arch:loong64) ###
"test-assembler-loong64.cc",
"test-disasm-loong64.cc",
"test-macro-assembler-loong64.cc",
]
}
if (v8_use_perfetto) {
# Perfetto doesn't use TraceObject.
sources -= [ "test-trace-event.cc" ]
}
configs = [
"../..:cppgc_base_config",
"../..:external_config",
"../..:internal_config_base",
"../..:v8_tracing_config",
":cctest_sources_config",
]
public_deps = [
":cctest_headers",
"..:common_test_headers",
"../..:v8_for_testing",
Reland of land "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2396933002/ ) Reason for revert: let's see whether it sticks this time Original issue's description: > Revert of Reland "Turn libbase into a component" (patchset #1 id:1 of https://codereview.chromium.org/2395553002/ ) > > Reason for revert: > Speculative revert due to very strange-looking win/dbg failures > which reference SignedDivisionByConstant: > > https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/12736 > > Original issue's description: > > Reland "Turn libbase into a component" > > > > Original issue's description: > > > Turn libbase into a component > > > > > > This is a precondition for turning libplatform into a component > > > > > > BUG=v8:5412 > > > R=jgruber@chromium.org,machenbach@chromium.org > > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_ > > dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe > > > > > > Committed: https://crrev.com/614e615775f732d71b5ee94ed29737d8de687104 > > > Cr-Commit-Position: refs/heads/master@{#39950} > > > > BUG=v8:5412 > > TBR=jgruber@chromium.org,machenbach@chromium.org > > CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_compile_dbg_ng;master.tryserver.chromium.android:android_clang_dbg_recipe;master.tryserver.chromium.mac:mac_chromium_compile_dbg_ng > > > > Committed: https://crrev.com/17cb51254cafa932025e9980b60f89f756d411cb > > Cr-Commit-Position: refs/heads/master@{#39969} > > TBR=jgruber@chromium.org,machenbach@chromium.org,jochen@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5412 > > Committed: https://crrev.com/e75b9f6ed5da39e6c7a8d70cf48afbc9958afc85 > Cr-Commit-Position: refs/heads/master@{#40009} TBR=jgruber@chromium.org,machenbach@chromium.org,adamk@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=v8:5412 Review-Url: https://codereview.chromium.org/2399323002 Cr-Commit-Position: refs/heads/master@{#40068}
2016-10-07 07:56:43 +00:00
"../..:v8_libbase",
"../..:v8_libplatform",
Reland "Add postmortem debugging helper library" This is a reland of 517ab73fd7e3fdb70220b9699bca4c69a32e212e Updates since original: now compressed pointers passed to the function GetObjectProperties are required to be sign-extended. Previously, the function allowed zero-extended values, but that led to ambiguity on pointers like 0x88044919: is it compressed or is the heap range actually centered on 0x100000000? Original change's description: > Add postmortem debugging helper library > > This change begins to implement the functionality described in > https://docs.google.com/document/d/1evHnb1uLlSbvHAAsmOXyc25x3uh1DjgNa8u1RHvwVhk/edit# > for investigating V8 state in crash dumps. > > This change adds a new library, v8_debug_helper, for providing platform- > agnostic assistance with postmortem debugging. This library can be used > by extensions built for debuggers such as WinDbg or lldb. Its public API > is described by debug-helper.h; currently the only method it exposes is > GetObjectProperties, but we'd like to add more functionality over time. > The API surface is restricted to plain C-style structs and pointers, so > that it's easy to link from a debugger extension built with a different > toolchain. > > This change also adds a new cctest file to exercise some basic > interaction with the new library. > > The API function GetObjectProperties takes an object pointer (which > could be compressed, or weak, or a SMI), and returns a string > description of the object and a list of properties the object contains. > For now, the list of properties is entirely based on Torque object > definitions, but we expect to add custom properties in future updates so > that it can be easier to make sense of complex data structures such as > dictionaries. > > GetObjectProperties does several things that are intended to generate > somewhat useful results even in cases where memory may be corrupt or > unavailable: > - The caller may optionally provide a type string which will be used if > the memory for the object's Map is inaccessible. > - All object pointers are compared against the list of known objects > generated by mkgrokdump. The caller may optionally provide the > pointers for the first pages of various heap spaces, to avoid spurious > matches. If those pointers are not provided, then any matches are > prefixed with "maybe" in the resulting description string, such as > "maybe UndefinedValue (0x4288000341 <Oddball>)". > > Bug: v8:9376 > > Change-Id: Iebf3cc2dea3133c7811bcefcdf38d9458b02fded > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628012 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Michael Stanton <mvstanton@chromium.org> > Cr-Commit-Position: refs/heads/master@{#62882} Bug: v8:9376 Change-Id: I866a1cc9d4c34bfe10c7b98462451fe69763cf3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717090 Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63008}
2019-07-30 14:38:15 +00:00
"../../tools/debug_helper:v8_debug_helper",
"//build/win:default_exe_manifest",
]
if (v8_enable_webassembly) {
sources += [
"../common/wasm/flag-utils.h",
"../common/wasm/test-signatures.h",
"../common/wasm/wasm-macro-gen.h",
"compiler/test-multiple-return.cc",
# test-run-native-calls uses wasm's LinkageAllocator.
"compiler/test-run-native-calls.cc",
"test-api-wasm.cc",
"test-js-to-wasm.cc",
"wasm/test-backing-store.cc",
"wasm/test-c-wasm-entry.cc",
"wasm/test-compilation-cache.cc",
"wasm/test-gc.cc",
"wasm/test-grow-memory.cc",
"wasm/test-jump-table-assembler.cc",
"wasm/test-liftoff-for-fuzzing.cc",
"wasm/test-liftoff-inspection.cc",
"wasm/test-run-wasm-64.cc",
"wasm/test-run-wasm-asmjs.cc",
"wasm/test-run-wasm-atomics.cc",
"wasm/test-run-wasm-atomics64.cc",
"wasm/test-run-wasm-bulk-memory.cc",
"wasm/test-run-wasm-exceptions.cc",
"wasm/test-run-wasm-interpreter.cc",
"wasm/test-run-wasm-js.cc",
"wasm/test-run-wasm-memory64.cc",
"wasm/test-run-wasm-module.cc",
"wasm/test-run-wasm-relaxed-simd.cc",
"wasm/test-run-wasm-sign-extension.cc",
"wasm/test-run-wasm-simd-liftoff.cc",
"wasm/test-run-wasm-simd.cc",
"wasm/test-run-wasm-wrappers.cc",
"wasm/test-run-wasm.cc",
"wasm/test-streaming-compilation.cc",
"wasm/test-wasm-breakpoints.cc",
"wasm/test-wasm-codegen.cc",
"wasm/test-wasm-import-wrapper-cache.cc",
"wasm/test-wasm-metrics.cc",
"wasm/test-wasm-serialization.cc",
"wasm/test-wasm-shared-engine.cc",
"wasm/test-wasm-stack.cc",
"wasm/test-wasm-trap-position.cc",
"wasm/wasm-atomics-utils.h",
"wasm/wasm-run-utils.cc",
"wasm/wasm-run-utils.h",
"wasm/wasm-simd-utils.cc",
"wasm/wasm-simd-utils.h",
]
public_deps += [ "../..:wasm_test_common" ]
}
defines = []
deps = [
"../..:run_torque",
"../..:v8_shared_internal_headers",
]
if (v8_enable_i18n_support) {
defines += [ "V8_INTL_SUPPORT" ]
public_deps += [ "//third_party/icu" ]
} else {
sources -= [ "test-intl.cc" ]
}
cflags = []
if (v8_current_cpu == "ppc" || v8_current_cpu == "ppc64" ||
v8_current_cpu == "arm" || v8_current_cpu == "arm64" ||
v8_current_cpu == "s390" || v8_current_cpu == "s390x" ||
v8_current_cpu == "mips" || v8_current_cpu == "mips64" ||
v8_current_cpu == "mipsel" || v8_current_cpu == "mipsel64" ||
v8_current_cpu == "riscv64" || v8_current_cpu == "loong64") {
# Disable fmadd/fmsub so that expected results match generated code in
# RunFloat64MulAndFloat64Add1 and friends.
Reland "Add Windows ARM64 ABI support to V8" This is a reland of fcbb023b0e09962453b68609341d21fbb17bf9fe Original change's description: > Add Windows ARM64 ABI support to V8 > > This change added Windows ARM64 ABI support, major things are: > 1. Excluding x18 register from any usage because it is reserved as > platform register. Preserve alignment after the change. > 2. Fix the assumption of LP64 in arm64 backend. Windows ARM64 is > still LLP64. > 3. Stack guard page probe for large allocation on stack. > > Reference: > Windows ARM64 ABI: > https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2017 > > Bug: chromium:893460 > Change-Id: I325884ac8dab719154a0047141e18a9fcb8dff7e > Reviewed-on: https://chromium-review.googlesource.com/c/1285129 > Commit-Queue: Michael Achenbach <machenbach@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#56881} CQ_INCLUDE_TRYBOTS=luci.chromium.try:android_arm64_dbg_recipe TBR=mlippautz@chromium.org Bug: chromium:893460 Change-Id: Icc45fd091c33f7df805842a70236b79b14756f52 Reviewed-on: https://chromium-review.googlesource.com/c/1297300 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#56965}
2018-10-23 23:30:20 +00:00
if (!is_win) {
cflags += [ "-ffp-contract=off" ]
}
}
if (is_win) {
# This warning is benignly triggered by the U16 and U32 macros in
# bytecode-utils.h.
# C4309: 'static_cast': truncation of constant value
cflags += [ "/wd4309" ]
# MSVS wants this for gay-{precision,shortest}.cc.
cflags += [ "/bigobj" ]
if (symbol_level == 2) {
sources += [ "test-v8windbg.cc" ]
deps += [ "../../tools/v8windbg:v8windbg_test" ]
}
}
[tracing] Add a way to test perfetto traces. Add a new abstract class TraceEventListener which is just an interface for consuming trace events. This separates the V8-specific stuff that an actual perfetto consumer needs to do e.g. handling the has_more flag and signalling back to the controller with a semaphore. This is a change from the previous plan of making the PerfettoConsumer class sub-classable to implement custom consumption of trace events. This will be difficult when the consumer is created outside of the PerfettoTracingController as we can't hook up the consumer_finished_semaphore_ that belongs to the controller. Now the PerfettoTracingController is responsible for the Consumer life- cycle and hides it entirely from callers. We add the AddTraceEventListener() method to allow callers to register a listener either for testing or a JSON listener for real tracing. This lets us write tests that can store all the trace events in memory without first converting them to JSON, letting us write test more easily. There's an example test add to test-tracing - more tests using this style will follow. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: I2d2b0f408b1c7bed954144163e1968f40d772c1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628789 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61854}
2019-05-27 12:46:35 +00:00
if (v8_use_perfetto) {
deps += [
# TODO(skyostil): Migrate to protozero.
"//third_party/perfetto/protos/perfetto/trace:lite",
]
[tracing] Add a way to test perfetto traces. Add a new abstract class TraceEventListener which is just an interface for consuming trace events. This separates the V8-specific stuff that an actual perfetto consumer needs to do e.g. handling the has_more flag and signalling back to the controller with a semaphore. This is a change from the previous plan of making the PerfettoConsumer class sub-classable to implement custom consumption of trace events. This will be difficult when the consumer is created outside of the PerfettoTracingController as we can't hook up the consumer_finished_semaphore_ that belongs to the controller. Now the PerfettoTracingController is responsible for the Consumer life- cycle and hides it entirely from callers. We add the AddTraceEventListener() method to allow callers to register a listener either for testing or a JSON listener for real tracing. This lets us write tests that can store all the trace events in memory without first converting them to JSON, letting us write test more easily. There's an example test add to test-tracing - more tests using this style will follow. Cq-Include-Trybots: luci.v8.try:v8_linux64_perfetto_dbg_ng Bug: v8:8339 Change-Id: I2d2b0f408b1c7bed954144163e1968f40d772c1b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1628789 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Peter Marshall <petermarshall@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#61854}
2019-05-27 12:46:35 +00:00
}
}
v8_executable("generate-bytecode-expectations") {
testonly = true
sources = [
"interpreter/bytecode-expectations-printer.cc",
"interpreter/bytecode-expectations-printer.h",
"interpreter/generate-bytecode-expectations.cc",
]
configs = [
"../..:external_config",
"../..:internal_config_base",
]
deps = [
":cctest_headers",
"../..:v8",
"../..:v8_libbase",
"../..:v8_libplatform",
"//build/win:default_exe_manifest",
]
data = [ "interpreter/bytecode_expectations/" ]
}