- 20 Jan, 2021 1 commit
-
-
Seth Brenith authored
This change adds Torque field definitions for ScopeInfo and begins to use the Torque-generated accessors in some places. It does not change the in-memory layout of ScopeInfo. Torque compiler changes: - Fix an issue where the parser created constexpr types for classes based on the class name rather than the `generates` clause. This meant that generated accessors referred to the imaginary type HashTable rather than the real C++ type FixedArray. - Don't pass Isolate* through the generated runtime functions that implement Torque macros. Maybe we'll need it eventually, but we don't right now and it complicates a lot of things. - Don't emit `kSomeFieldOffset` if some_field has an unknown offset. Instead, emit a member function `SomeFieldOffset()` which fetches the slice for some_field and returns its offset. - Emit an `AllocatedSize()` member function for classes which have complex length expressions. It fetches the slice for the last field and performs the multiply&add to compute the total object size. - Emit field accessors for fields with complex length expressions, using the new offset functions. - Fix a few minor bugs where Torque can write uncompilable code. With this change, most code still treats ScopeInfo like a FixedArray, so I would like to follow up with some additional changes: 1. Generate a GC visitor for ScopeInfo and use it 2. Generate accessors for struct-typed fields (indexed or otherwise), and use them 3. Get rid of the FixedArray-style get and set accessors; use TaggedField::load and similar instead 4. Inherit from HeapObject rather than FixedArrayBase to remove the unnecessary `length` field After that, there will only be one ugly part left: initialization. I think it's possible to generate a factory function that takes a bunch of iterator parameters and returns a fully-formed, verifiably correct ScopeInfo instance, but doing so is more complicated than the four mostly-mechanical changes listed above. Bug: v8:7793 Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72187}
-
- 19 Jan, 2021 1 commit
-
-
Z Nguyen-Huu authored
Docs: https://docs.google.com/document/d/13n1qaB6A-gvgWc9NDhWm-UPuOqow_Y0DNgCeTbtIotI Modify that C++ backend so that it can emit either runtime C++ or postmortem debugging code. When in postmortem debugging mode, the overall code structure would look similar with some difference: 1. Instead of passing an Isolate* everywhere, we pass a MemoryAccessor. 2. Instead of runtime class names like String, we use uintptr_t 3. When loading data from objects, instead of TaggedField<T>::load or Object::ReadField (which read from the current process), we use the MemoryAccessor and read data from the debuggee process. 4. Return values should be wrapped in the Value struct. Implement the debug accessors for complex length expressions and add test for such class (SmallOrderedHashSet). Change-Id: I34107c92b31ed4e07bb628ae58c84487e41ba648 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2477921 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72148}
-
- 13 Oct, 2020 1 commit
-
-
Seth Brenith authored
This change updates verifier generation to: - Fix a bug I introduced in https://crrev.com/c/2047399 that caused values within struct-typed fields to not get verified - Support indexed fields with start offsets that are not known at compile time - Support indexed fields with complex length expressions Bug: v8:7793 Change-Id: I5ae8803fce59abae0989fcb094bd9692cd88e38e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461456 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70490}
-
- 05 Oct, 2020 1 commit
-
-
Seth Brenith authored
This change adds a new code generator, which supports a subset of the instructions supported by the existing CSAGenerator, and instead of generating CSA it generates runtime C++ code. The new generator is used to generate a set of Torque macros that return slices to indexed fields. These new macros should be sufficient to eventually support Torque-generated field accessors, BodyDescriptors, verifier functions, and postmortem field inspection in debug_helper. Bug: v8:7793 Change-Id: Ife2d25cfd55a08238c625a8b04aca3ff2a0f4c63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429566Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70313}
-