dart-sdk/runtime/vm/vm_sources.gni

469 lines
10 KiB
Text
Raw Normal View History

# Copyright (c) 2017, the Dart project authors. Please see the AUTHORS file
# for details. All rights reserved. Use of this source code is governed by a
# BSD-style license that can be found in the LICENSE file.
# This file contains all sources (vm and tests) for the dart virtual machine.
# Unit test files need to have a "_test" suffix appended to the name.
vm_sources = [
"allocation.cc",
"allocation.h",
"base64.cc",
"base64.h",
"base_isolate.h",
"bit_vector.cc",
"bit_vector.h",
"bitfield.h",
"bitmap.cc",
"bitmap.h",
"boolfield.h",
"bootstrap.h",
"bootstrap_natives.cc",
"bootstrap_natives.h",
"bss_relocs.cc",
"bss_relocs.h",
"canonical_tables.cc",
"canonical_tables.h",
"class_finalizer.cc",
"class_finalizer.h",
[vm] Decouple assemblers from runtime. This is the next step towards preventing compiler from directly peeking into runtime and instead interact with runtime through a well defined surface. The goal of the refactoring to locate all places where compiler accesses some runtime information and partion those accesses into two categories: - creating objects in the host runtime (e.g. allocating strings, numbers, etc) during compilation; - accessing properties of the target runtime (e.g. offsets of fields) to embed those into the generated code; This change introduces dart::compiler and dart::compiler::target namespaces. All code in the compiler will gradually be moved into dart::compiler namespace. One of the motivations for this change is to be able to prevent access to globally defined host constants like kWordSize by shadowing them in the dart::compiler namespace. The nested namespace dart::compiler::target hosts all information about target runtime that compiler could access, e.g. compiler::target::kWordSize defines word size of the target which will eventually be made different from the host kWordSize (defined by dart::kWordSize). The API for compiler to runtime interaction is placed into compiler_api.h. Note that we still permit runtime to access compiler internals directly - this is not going to be decoupled as part of this work. Issue https://github.com/dart-lang/sdk/issues/31709 Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20 Reviewed-on: https://dart-review.googlesource.com/c/90242 Commit-Queue: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com>
2019-01-25 16:45:13 +00:00
"class_id.h",
"class_table.cc",
"class_table.h",
"closure_functions_cache.cc",
"closure_functions_cache.h",
"clustered_snapshot.cc",
"clustered_snapshot.h",
"code_comments.cc",
"code_comments.h",
"code_descriptors.cc",
"code_descriptors.h",
[vm] Decouple assemblers from runtime. This is the next step towards preventing compiler from directly peeking into runtime and instead interact with runtime through a well defined surface. The goal of the refactoring to locate all places where compiler accesses some runtime information and partion those accesses into two categories: - creating objects in the host runtime (e.g. allocating strings, numbers, etc) during compilation; - accessing properties of the target runtime (e.g. offsets of fields) to embed those into the generated code; This change introduces dart::compiler and dart::compiler::target namespaces. All code in the compiler will gradually be moved into dart::compiler namespace. One of the motivations for this change is to be able to prevent access to globally defined host constants like kWordSize by shadowing them in the dart::compiler namespace. The nested namespace dart::compiler::target hosts all information about target runtime that compiler could access, e.g. compiler::target::kWordSize defines word size of the target which will eventually be made different from the host kWordSize (defined by dart::kWordSize). The API for compiler to runtime interaction is placed into compiler_api.h. Note that we still permit runtime to access compiler internals directly - this is not going to be decoupled as part of this work. Issue https://github.com/dart-lang/sdk/issues/31709 Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20 Reviewed-on: https://dart-review.googlesource.com/c/90242 Commit-Queue: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com>
2019-01-25 16:45:13 +00:00
"code_entry_kind.h",
"code_observers.cc",
"code_observers.h",
"code_patcher.cc",
"code_patcher.h",
"code_patcher_arm.cc",
"code_patcher_arm64.cc",
"code_patcher_ia32.cc",
"code_patcher_x64.cc",
"compilation_trace.cc",
"compilation_trace.h",
"constants_arm.cc",
"constants_arm.h",
"constants_arm64.cc",
"constants_arm64.h",
[vm] Clean up header file style guide violation > Header files should be self-contained (compile on their own) and end in .h. Non-header files that are meant for inclusion should end in .inc and be used sparingly. > > All header files should be self-contained. Users and refactoring tools should not have to adhere to special conditions to include the header. Specifically, a header should have header guards and include all other headers it needs. This cleans up header files referring to types and functions defined in the files including those header files. This does not clean up the include guards in xyz_<arch>.h. We have currently 45 such include guards. We can clean that up by moving the #ifdefs from xyz.h to the individual xyz_<arch>.h files. A list of header files which cannot stand on itself is maintained in runtime/tools/run_clang_tidy.dart. Change-Id: I9ab1fc09056d86e8ac59a80c063a812633cf7c71 Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,app-kernel-linux-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-kernel-precomp-linux-debug-x64-try,vm-dartkb-linux-release-x64-abi-try,vm-kernel-precomp-android-release-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,dart-sdk-linux-try,analyzer-analysis-server-linux-try,analyzer-linux-release-try,front-end-linux-release-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-mac-debug-x64-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/135650 Commit-Queue: Daco Harkes <dacoharkes@google.com> Reviewed-by: Alexander Markov <alexmarkov@google.com>
2020-02-18 08:43:16 +00:00
"constants_base.h",
"constants_ia32.cc",
"constants_ia32.h",
"constants_x64.cc",
"constants_x64.h",
"cpu.h",
"cpu_arm.cc",
"cpu_arm64.cc",
"cpu_ia32.cc",
"cpu_x64.cc",
"cpuid.cc",
"cpuid.h",
"cpuinfo.h",
"cpuinfo_android.cc",
"cpuinfo_fuchsia.cc",
"cpuinfo_linux.cc",
"cpuinfo_macos.cc",
"cpuinfo_win.cc",
"dart.cc",
"dart.h",
"dart_api_impl.h",
"dart_api_message.cc",
"dart_api_message.h",
"dart_api_state.cc",
"dart_api_state.h",
"dart_entry.cc",
"dart_entry.h",
"datastream.cc",
"datastream.h",
"debugger.cc",
"debugger.h",
"debugger_arm.cc",
"debugger_arm64.cc",
"debugger_ia32.cc",
"debugger_x64.cc",
"deferred_objects.cc",
"deferred_objects.h",
"deopt_instructions.cc",
"deopt_instructions.h",
[vm/aot] Use a global dispatch table for instance calls in AOT. This is a Dart-tailored implementation of the "row-displacement dispatch table" technique for closed-world instance calls: All interface targets in the program are grouped into selectors such that all targets that could potentially be called from the same call site have the same selector (currently just grouped by name). Each selector is assigned a selector offset such that offset + classid is unique for all selector/classid combinations where the class implements the selector. At every instance call site that has an interface target (i.e. where the static type of the receiver is not dynamic), the selector offset + receiver classid is computed and used as index into a global table of entry points. If the receiver can be null (as determined by the front-end TFA and the VM type propagation), a null check is inserted before the call. An arguments descriptor is provided (only) for selectors that need it (those which have type parameters or optional/named parameters). The dispatch table calls don't need the monomorphic entry code, so for functions that are only called via dispatch table calls (i.e. never called dynamically), the monomorphic entry code is left out. Some future improvements to the table dispatch implementation are mentioned in https://github.com/dart-lang/sdk/issues/40188 The table dispatch flag is disabled by default in this commit. A separate commit enables the flag. Change-Id: Ic2911742b4a2c9a8d3bc7df60605454cbe4c0714 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/126648 Commit-Queue: Aske Simon Christensen <askesc@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com> Reviewed-by: Alexander Markov <alexmarkov@google.com>
2020-02-03 11:04:15 +00:00
"dispatch_table.cc",
"dispatch_table.h",
"double_conversion.cc",
"double_conversion.h",
"double_internals.h",
"dwarf.cc",
"dwarf.h",
"elf.cc",
"elf.h",
"exceptions.cc",
"exceptions.h",
"experimental_features.cc",
"experimental_features.h",
"ffi_callback_trampolines.cc",
"ffi_callback_trampolines.h",
"field_table.cc",
"field_table.h",
"finalizable_data.h",
"fixed_cache.h",
"flag_list.h",
"flags.cc",
"flags.h",
[vm] Decouple assemblers from runtime. This is the next step towards preventing compiler from directly peeking into runtime and instead interact with runtime through a well defined surface. The goal of the refactoring to locate all places where compiler accesses some runtime information and partion those accesses into two categories: - creating objects in the host runtime (e.g. allocating strings, numbers, etc) during compilation; - accessing properties of the target runtime (e.g. offsets of fields) to embed those into the generated code; This change introduces dart::compiler and dart::compiler::target namespaces. All code in the compiler will gradually be moved into dart::compiler namespace. One of the motivations for this change is to be able to prevent access to globally defined host constants like kWordSize by shadowing them in the dart::compiler namespace. The nested namespace dart::compiler::target hosts all information about target runtime that compiler could access, e.g. compiler::target::kWordSize defines word size of the target which will eventually be made different from the host kWordSize (defined by dart::kWordSize). The API for compiler to runtime interaction is placed into compiler_api.h. Note that we still permit runtime to access compiler internals directly - this is not going to be decoupled as part of this work. Issue https://github.com/dart-lang/sdk/issues/31709 Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20 Reviewed-on: https://dart-review.googlesource.com/c/90242 Commit-Queue: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com>
2019-01-25 16:45:13 +00:00
"frame_layout.h",
"gdb_helpers.cc",
"globals.h",
"growable_array.h",
[vm] Decouple assemblers from runtime. This is the next step towards preventing compiler from directly peeking into runtime and instead interact with runtime through a well defined surface. The goal of the refactoring to locate all places where compiler accesses some runtime information and partion those accesses into two categories: - creating objects in the host runtime (e.g. allocating strings, numbers, etc) during compilation; - accessing properties of the target runtime (e.g. offsets of fields) to embed those into the generated code; This change introduces dart::compiler and dart::compiler::target namespaces. All code in the compiler will gradually be moved into dart::compiler namespace. One of the motivations for this change is to be able to prevent access to globally defined host constants like kWordSize by shadowing them in the dart::compiler namespace. The nested namespace dart::compiler::target hosts all information about target runtime that compiler could access, e.g. compiler::target::kWordSize defines word size of the target which will eventually be made different from the host kWordSize (defined by dart::kWordSize). The API for compiler to runtime interaction is placed into compiler_api.h. Note that we still permit runtime to access compiler internals directly - this is not going to be decoupled as part of this work. Issue https://github.com/dart-lang/sdk/issues/31709 Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20 Reviewed-on: https://dart-review.googlesource.com/c/90242 Commit-Queue: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com>
2019-01-25 16:45:13 +00:00
"handle_visitor.h",
"handles.cc",
"handles.h",
"handles_impl.h",
"hash_map.h",
"hash_table.h",
"image_snapshot.cc",
"image_snapshot.h",
"instructions.h",
"instructions_arm.cc",
"instructions_arm.h",
"instructions_arm64.cc",
"instructions_arm64.h",
"instructions_ia32.cc",
"instructions_ia32.h",
"instructions_x64.cc",
"instructions_x64.h",
"intrusive_dlist.h",
"isolate.cc",
"isolate.h",
"isolate_reload.cc",
"isolate_reload.h",
"json_stream.cc",
"json_stream.h",
"json_writer.cc",
"json_writer.h",
"kernel.cc",
"kernel.h",
"kernel_binary.cc",
"kernel_binary.h",
"kernel_isolate.cc",
"kernel_isolate.h",
"kernel_loader.cc",
"kernel_loader.h",
"lockers.cc",
"lockers.h",
"log.cc",
"log.h",
"longjump.cc",
"longjump.h",
"malloc_hooks.h",
"malloc_hooks_arm.cc",
"malloc_hooks_arm64.cc",
"malloc_hooks_ia32.cc",
"malloc_hooks_tcmalloc.cc",
"malloc_hooks_unsupported.cc",
"malloc_hooks_x64.cc",
"megamorphic_cache_table.cc",
"megamorphic_cache_table.h",
"memory_region.cc",
"memory_region.h",
"message.cc",
"message.h",
"message_handler.cc",
"message_handler.h",
"metrics.cc",
"metrics.h",
"native_arguments.h",
"native_entry.cc",
"native_entry.h",
"native_message_handler.cc",
"native_message_handler.h",
"native_symbol.h",
"native_symbol_android.cc",
"native_symbol_fuchsia.cc",
"native_symbol_linux.cc",
"native_symbol_macos.cc",
"native_symbol_win.cc",
"object.cc",
"object.h",
"object_graph.cc",
"object_graph.h",
"object_id_ring.cc",
"object_id_ring.h",
"object_reload.cc",
"object_service.cc",
"object_set.h",
"object_store.cc",
"object_store.h",
"os.h",
"os_android.cc",
"os_fuchsia.cc",
"os_linux.cc",
"os_macos.cc",
"os_thread.cc",
"os_thread.h",
"os_thread_android.cc",
"os_thread_android.h",
"os_thread_fuchsia.cc",
"os_thread_fuchsia.h",
"os_thread_linux.cc",
"os_thread_linux.h",
"os_thread_macos.cc",
"os_thread_macos.h",
"os_thread_win.cc",
"os_thread_win.h",
"os_win.cc",
"parser.cc",
"parser.h",
"pending_deopts.cc",
"pending_deopts.h",
[vm] Decouple assemblers from runtime. This is the next step towards preventing compiler from directly peeking into runtime and instead interact with runtime through a well defined surface. The goal of the refactoring to locate all places where compiler accesses some runtime information and partion those accesses into two categories: - creating objects in the host runtime (e.g. allocating strings, numbers, etc) during compilation; - accessing properties of the target runtime (e.g. offsets of fields) to embed those into the generated code; This change introduces dart::compiler and dart::compiler::target namespaces. All code in the compiler will gradually be moved into dart::compiler namespace. One of the motivations for this change is to be able to prevent access to globally defined host constants like kWordSize by shadowing them in the dart::compiler namespace. The nested namespace dart::compiler::target hosts all information about target runtime that compiler could access, e.g. compiler::target::kWordSize defines word size of the target which will eventually be made different from the host kWordSize (defined by dart::kWordSize). The API for compiler to runtime interaction is placed into compiler_api.h. Note that we still permit runtime to access compiler internals directly - this is not going to be decoupled as part of this work. Issue https://github.com/dart-lang/sdk/issues/31709 Change-Id: If4396d295879391becfa6c38d4802bbff81f5b20 Reviewed-on: https://dart-review.googlesource.com/c/90242 Commit-Queue: Vyacheslav Egorov <vegorov@google.com> Reviewed-by: Martin Kustermann <kustermann@google.com>
2019-01-25 16:45:13 +00:00
"pointer_tagging.h",
"port.cc",
"port.h",
"port_set.h",
"proccpuinfo.cc",
"proccpuinfo.h",
"profiler.cc",
"profiler.h",
"profiler_service.cc",
"profiler_service.h",
"program_visitor.cc",
"program_visitor.h",
"random.cc",
"random.h",
"raw_object.cc",
"raw_object.h",
"raw_object_fields.cc",
"raw_object_fields.h",
"raw_object_snapshot.cc",
"regexp.cc",
"regexp.h",
"regexp_assembler.cc",
"regexp_assembler.h",
"regexp_assembler_bytecode.cc",
"regexp_assembler_bytecode.h",
"regexp_assembler_bytecode_inl.h",
"regexp_assembler_ir.cc",
"regexp_assembler_ir.h",
"regexp_ast.cc",
"regexp_ast.h",
"regexp_bytecodes.h",
"regexp_interpreter.cc",
"regexp_interpreter.h",
"regexp_parser.cc",
"regexp_parser.h",
"report.cc",
"report.h",
"resolver.cc",
"resolver.h",
"reusable_handles.h",
"reverse_pc_lookup_cache.cc",
"reverse_pc_lookup_cache.h",
"ring_buffer.h",
"runtime_entry.cc",
"runtime_entry.h",
"runtime_entry_arm.cc",
"runtime_entry_arm64.cc",
"runtime_entry_ia32.cc",
"runtime_entry_list.h",
"runtime_entry_x64.cc",
"scope_timer.h",
"scopes.cc",
"scopes.h",
"service.cc",
"service.h",
"service_event.cc",
"service_event.h",
"service_isolate.cc",
"service_isolate.h",
"signal_handler.h",
"signal_handler_android.cc",
"signal_handler_fuchsia.cc",
"signal_handler_linux.cc",
"signal_handler_macos.cc",
"signal_handler_win.cc",
"simulator.h",
"simulator_arm.cc",
"simulator_arm.h",
"simulator_arm64.cc",
"simulator_arm64.h",
"snapshot.cc",
"snapshot.h",
"snapshot_ids.h",
"source_report.cc",
"source_report.h",
"stack_frame.cc",
"stack_frame.h",
"stack_frame_arm.h",
"stack_frame_arm64.h",
"stack_frame_ia32.h",
"stack_frame_x64.h",
"stack_trace.cc",
"stack_trace.h",
"static_type_exactness_state.h",
"stub_code.cc",
"stub_code.h",
"stub_code_list.h",
"symbols.cc",
"symbols.h",
"tags.cc",
"tags.h",
"thread.cc",
"thread.h",
"thread_barrier.h",
"thread_interrupter.cc",
"thread_interrupter.h",
"thread_interrupter_android.cc",
"thread_interrupter_fuchsia.cc",
"thread_interrupter_linux.cc",
"thread_interrupter_macos.cc",
"thread_interrupter_win.cc",
"thread_pool.cc",
"thread_pool.h",
"thread_registry.cc",
"thread_registry.h",
"thread_stack_resource.cc",
"thread_stack_resource.h",
"thread_state.cc",
"thread_state.h",
"timeline.cc",
"timeline.h",
"timeline_analysis.cc",
"timeline_analysis.h",
"timeline_android.cc",
"timeline_fuchsia.cc",
"timeline_linux.cc",
"timeline_macos.cc",
"timer.cc",
"timer.h",
"token.cc",
"token.h",
"token_position.cc",
"token_position.h",
Reland "[VM] Introduction of type testing stubs - Part 1-4" Relands 165c583d57af613836cf7d08242ce969521db00b [VM] Introduction of type testing stubs - Part 1 This CL: * Adds a field to [RawAbstractType] which will always hold a pointer to the entrypoint of a type testing stub * Makes this new field be initialized to a default stub whenever a instances are created (e.g. via Type::New(), snapshot reader, ...) * Makes the clustered snapshotter write a reference to the corresponding [RawInstructions] object when writing the field and do the reverse when reading it. * Makes us call the type testing stub for performing assert-assignable checks. To reduce unnecessary loads on callsites, we store the entrypoint of the type testing stubs directly in the type objects. This means that the caller of type testing stubs can simply branch there without populating a code object first. This also means that the type testing stubs themselves have no access to a pool and we therefore also don't hold on to the [Code] object, only the [Instruction] object is necessary. The type testing stubs do not setup a frame themselves and also have no safepoint. In the case when the type testing stubs could not determine a positive answer they will tail-call a general-purpose stub. The general-purpose stub sets up a stub frame, tries to consult a [SubtypeTestCache] and bails out to runtime if this was unsuccessful. This CL is just the the first, for ease of reviewing. The actual type-specialized type testing stubs will be generated in later CLs. Reviewed-on: https://dart-review.googlesource.com/44787 Relands f226c22424c483d65499545e560efc059f9dde1c [VM] Introduction of type testing stubs - Part 2 This CL starts building type testing stubs specialzed for [Type] objects we test against. More specifically, it adds support for: * Handling obvious fast cases on the call sites (while still having a call to stub for negative case) * Handling type tests against type parameters, by loading the value of the type parameter on the call sites and invoking it's type testing stub. * Specialzed type testing stubs for instantiated types where we can do [CidRange]-based subtype-checks. ==> e.g. String/List<dynamic> * Specialzed type testing stubs for instantiated types where we can do [CidRange]-based subclass-checks for the class and [CidRange]-based subtype-checks for the type arguments. ==> e.g. Widget<State>, where we know [Widget] is only extended and not implemented. * Specialzed type testing stubs for certain non-instantiated types where we can do [CidRange]-based subclass-checks for the class and [CidRange]-based subtype-checks for the instantiated type arguments and cid based comparisons for type parameters. (Note that this fast-case migth result in some false-negatives!) ==> e.g. _HashMapEntry<K, V>, where we know [_HashMapEntry] is only extended and not implemented. This optimizes cases where the caller uses `new HashMap<A, B>()` and only uses `A` and `B` as key/values (and not subclasses of it). The false-negative can occur when subtypes of A or B are used. In such cases we fall back to the [SubtypeTestCache]-based imlementation. Reviewed-on: https://dart-review.googlesource.com/44788 Relands 25f98bcc7561006d70a487ba3de55551658ac683 [VM] Introduction of type testing stubs - Part 3 The changes include: * Make AssertAssignableInstr no longer have a call-summary, which helps methods with several parameter checks by not having to re-load/re-initialize type arguments registers * Lazily create SubtypeTestCaches: We already go to runtime to warm up the caches, so we now also create the caches on the first runtime call and patch the pool entries. * No longer load the destination name into a register: We only need the name when we throw an exception, so it is not on the hot path. Instead we let the runtime look at the call site, decoding a pool index from the instructions stream. The destination name will be available in the pool, at a consecutive index to the subtype cache. * Remove the fall-through to N=1 case for probing subtypeing tests, since those will always be handled by the optimized stubs. * Do not generate optimized stubs for FutureOr<T> (so far it just falled-through to TTS). We can make optimzed version of that later, but it requires special subtyping rules. * Local code quality improvement in the type-testing-stubs: Avoid extra jump at last case of cid-class-range checks. There are still a number of optimization opportunities we can do in future changes. Reviewed-on: https://dart-review.googlesource.com/46984 Relands 2c52480ec87392992a1388517c46ccc97bdc9b2b [VM] Introduction of type testing stubs - Part 4 In order to avoid generating type testing stubs for too many types in the system - and thereby potentially cause an increase in code size - this change introduces a smarter way to decide for which types we should generate optimized type testing stubs. The precompiler creates a [TypeUsageInfo] which we use to collect information. More specifically: a) We collect the destination types for all type checks we emit (we do this inside AssertAssignableInstr::EmitNativeCode). -> These are types we might want to generate optimized type testing stubs for. b) We collect type argument vectors used in instance creations (we do this inside AllocateObjectInstr::EmitNativeCode) and keep a set of of used type argument vectors for each class. After the precompiler has finished compiling normal code we scan the set of destination types collected in a) for uninstantiated types (or more specifically, type parameter types). We then propagate the type argument vectors used on object allocation sites, which were collected in b), in order to find out what kind of types are flowing into those type parameters. This allows us to extend the set of types which we test against, by adding the types that flow into type parameters. We use this final augmented set of destination types as a "filter" when making the decision whether to generate an optimized type testing stub for a given type. Reviewed-on: https://dart-review.googlesource.com/48640 Issue https://github.com/dart-lang/sdk/issues/32603 Closes https://github.com/dart-lang/sdk/issues/32852 Change-Id: Ib79fbe7f043aa88f32bddad62d7656c638914b44 Reviewed-on: https://dart-review.googlesource.com/50944 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Régis Crelier <regis@google.com>
2018-04-13 09:06:56 +00:00
"type_testing_stubs.cc",
"type_testing_stubs.h",
"unibrow-inl.h",
"unibrow.cc",
"unibrow.h",
"unicode.cc",
"unicode_data.cc",
"uri.cc",
"uri.h",
"v8_snapshot_writer.cc",
"v8_snapshot_writer.h",
"virtual_memory.cc",
"virtual_memory.h",
"virtual_memory_compressed.cc",
"virtual_memory_compressed.h",
"virtual_memory_fuchsia.cc",
"virtual_memory_posix.cc",
"virtual_memory_win.cc",
"visitor.cc",
"visitor.h",
"zone.cc",
"zone.h",
"zone_text_buffer.cc",
"zone_text_buffer.h",
]
vm_sources_tests = [
"allocation_test.cc",
"assert_test.cc",
"atomic_test.cc",
"base64_test.cc",
"benchmark_test.cc",
"benchmark_test.h",
"bit_set_test.cc",
"bit_vector_test.cc",
"bitfield_test.cc",
"bitmap_test.cc",
"boolfield_test.cc",
"catch_entry_moves_test.cc",
"class_finalizer_test.cc",
"code_descriptors_test.cc",
"code_patcher_arm64_test.cc",
"code_patcher_arm_test.cc",
"code_patcher_ia32_test.cc",
"code_patcher_x64_test.cc",
"compiler_test.cc",
"cpu_test.cc",
"cpuinfo_test.cc",
"custom_isolate_test.cc",
"dart_api_impl_test.cc",
"datastream_test.cc",
"debugger_api_impl_test.cc",
"exceptions_test.cc",
"fixed_cache_test.cc",
"flags_test.cc",
"growable_array_test.cc",
"guard_field_test.cc",
"handles_test.cc",
"hash_map_test.cc",
"hash_table_test.cc",
"instructions_arm64_test.cc",
"instructions_arm_test.cc",
"instructions_ia32_test.cc",
"instructions_x64_test.cc",
"intrusive_dlist_test.cc",
"isolate_reload_test.cc",
"isolate_test.cc",
"json_test.cc",
"log_test.cc",
"longjump_test.cc",
"malloc_hooks_test.cc",
"memory_region_test.cc",
"message_handler_test.cc",
"message_test.cc",
"metrics_test.cc",
"mixin_test.cc",
"native_entry_test.cc",
"native_entry_test.h",
"object_arm64_test.cc",
"object_arm_test.cc",
"object_graph_test.cc",
"object_ia32_test.cc",
"object_id_ring_test.cc",
"object_store_test.cc",
"object_test.cc",
"object_x64_test.cc",
"os_test.cc",
"port_test.cc",
"profiler_test.cc",
"regexp_test.cc",
"ring_buffer_test.cc",
"scopes_test.cc",
"service_test.cc",
"snapshot_test.cc",
"source_report_test.cc",
"stack_frame_test.cc",
"stub_code_test.cc",
"stub_code_arm64_test.cc",
"stub_code_arm_test.cc",
"stub_code_ia32_test.cc",
"stub_code_x64_test.cc",
"thread_barrier_test.cc",
"thread_pool_test.cc",
"thread_test.cc",
"timeline_test.cc",
"type_testing_stubs_test.cc",
"unicode_test.cc",
"unit_test.cc",
"unit_test.h",
"uri_test.cc",
"utils_test.cc",
"virtual_memory_test.cc",
"zone_test.cc",
]
[test/ffi] Add C++ unit tests for all target ABIs This CL introduces unit tests for the Native* classes in compiler/ffi that can run for all supported target ABIs on any host architecture. The unit tests are compiled for all target ABIs with `tools/build.py run_ffi_unit_tests` and run for all target ABIs with `tools/test.py ffi_unit`. The unit test and tested code do not conceptually depend on having a DartVM. The tests are compiled with a custom `dart::Zone` and `platform/`. This enables compiling for all `TARGET_ARCH_*` and `TARGET_OS_*` on any host, and running unit tests for all target ABIs on any host. Because the `run_ffi_unit_tests` executables do not include the DartVM their build is quick (<10seconds) and they are small (~6MB) when compared to `run_vm_tests` (~250MB). The tests are added to the existing FFI QEMU bot to prevent adding an extra bot which would add checkout overhead. The unit tests themselves are set up to be fairly similar to vm/cc tests. The only difference is the NativeCallingConvention tests which are set up with `.expect` files for easy inspection and updating. TEST=runtime/vm/compiler/ffi/native_calling_convention_test.cc TEST=runtime/vm/compiler/ffi/native_location_test.cc TEST=runtime/vm/compiler/ffi/native_type_test.cc Change-Id: I7b8bf4de9ef070e7546472217e571a60362b9639 Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171725 Commit-Queue: Daco Harkes <dacoharkes@google.com> Reviewed-by: Clement Skau <cskau@google.com> Reviewed-by: Alexander Thomas <athom@google.com>
2020-11-16 16:10:55 +00:00
constants_sources = [
"constants_arm.cc",
"constants_arm.h",
"constants_arm64.cc",
"constants_arm64.h",
"constants_base.h",
"constants_ia32.cc",
"constants_ia32.h",
"constants_x64.cc",
"constants_x64.h",
]