- 01 Mar, 2021 1 commit
-
-
Dan Elphick authored
Split out all the headers from v8_compiler/v8_compiler_opt and v8_base_without_compiler into v8_internal_headers since the headers have inter-dependencies that otherwise make it impossible to satisfy gn check. Also adds new v8_header_set torque_runtime_support that exports src/torque/runtime-support.h separately from the generated headers. This reduces the number of gn check failures from 169 to 59. Bug: v8:7330 Change-Id: Ie7ebc894910b7efa02011a74da964e11995c7f4f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712569 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73104}
-
- 22 Feb, 2021 1 commit
-
-
Dan Elphick authored
Currently if gn check is enabled (with v8/third_party ignored), there are many errors due to headers being used without adding the proper dependency in BUILD.gn (or because it's being used transitively without a public_deps chain). This makes the number of errors go from 2114 to 195. Apart from adding dependencies, it also moves _v8_internal_Node_Print from objects-printer.cc to node.cc so it can see the Node::Print method which wouldn't otherwise be possible without a circular dependency. Also removes the previously deleted compiler/graph-builder-tester.h file. Bug: v8:7330 Change-Id: Icb34585fbef621588265cf4267cfc88ecbcf0a72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2702331Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#72908}
-
- 28 Jan, 2021 1 commit
-
-
Sami Kyostila authored
Bug: chromium:1006541 Change-Id: Ia3f1b16a4becd10bd4041f35e125aad7acc33949 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653235 Auto-Submit: Sami Kyöstilä <skyostil@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#72386}
-
- 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}
-
- 27 Oct, 2020 2 commits
-
-
Jakob Gruber authored
This reverts commit 3c49308a. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Clusterfuzz%20Mac64%20ASAN%20-%20debug%20builder/18360 Original change's description: > [DEPS] Add abseil to deps > > Add a dependency on the chromium abseil-cpp subdir mirror. > > Bug: v8:11006 > Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70786} TBR=rmcilroy@chromium.org,adamk@chromium.org,yangguo@chromium.org,hpayer@chromium.org,leszeks@chromium.org,victorgomes@chromium.org Change-Id: Iff2ac3b0da8725ec2df69aa527e5a4255ca3009c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:11006 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2501843Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70787}
-
Leszek Swirski authored
Add a dependency on the chromium abseil-cpp subdir mirror. Bug: v8:11006 Change-Id: Icaad757269d27c65bc368ed539f84c5bb79ee62d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2464940 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#70786}
-
- 25 Sep, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 64caf2b0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
-
- 22 Sep, 2020 2 commits
-
-
Francis McCabe authored
This reverts commit 64caf2b0. Reason for revert: Seems to be causing a failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809? Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} TBR=jgruber@chromium.org,tebbi@chromium.org Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#70065}
-
Tobias Tebbi authored
This is to establish a naming rule for Torque-generated files: - If the file is called foo/bar-tq..., then it is derived from a file foo/bar.tq - Otherwise it doesn't belong to a specific .tq file. So far, we attached -tq to all Torque-generated file names, where it sometimes corresponded to a .tq file name and sometimes not. It is not necessary to add -tq to file names to indicate that they are Torque-generated, since they are already in a directory called torque-generated, and we always refer to them as "torque-generated/filename", so there is no confusion even though some files now have the same name as a corresponding hand-written file, for example factory.cc. TBR: hpayer@chromium.org Bug: v8:7793 Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70060}
-
- 09 Sep, 2020 1 commit
-
-
Leszek Swirski authored
tools/debug_helper:run_mkgrokdump used to only depend on mkgrokdump. However, the snapshot can change without affecting the mkgrokdump binary itself. So, if the mkgrokdump binary doesn't change, then run_mkgrokdump doesn't run, even if the snapshot changed. This could cause mysterious test failures in incremental builds, in particular for tests testing the contents of heap-constants-gen.cc. Now, we make run_mkgrokdump depend on run_mksnapshot_default directly, so that snapshot updates force an mkgrokdump run. Change-Id: Ia3871e1b4fa15ec2dbc0bc5463afdb427cb39c61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400987 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69776}
-
- 23 Jun, 2020 1 commit
-
-
Z Nguyen-Huu authored
Get value from type payload, check and show bitset name. Change-Id: I6d0e0f30fca0b2aaddfd5f18abf948886552f2dc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2258815 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#68495}
-
- 12 May, 2020 1 commit
-
-
Omer Katz authored
This CL adds 2 new values to the EmbedderStackState enum with more explicit names. The old values are updated as aliases to the new values and marked as soon to be deprecated. This CL also moves the enum to v8-platform.h so that it can be reused by cppgc. Depracating individual values in an enum is supported by GCC only since version 6. Thus new macros were needed for the deprecation (which delegate to the existing macros when supported). GCC versions older than 6 are still used by the CQ bots. Bug: chromium:1056170 Change-Id: Id1ea73edfbbae282b0d8a3bb103dbbbf8ebd417e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188971 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67744}
-
- 17 Apr, 2020 1 commit
-
-
Sami Kyostila authored
This patch replaces V8's tracing implementation (i.e., the TRACE_EVENT macros) with the track event base implementation from Perfetto. The advantages of doing this are: 1) This allows us to remove most tracing-related backend code from V8. 2) V8 can start writing strongly typed trace event arguments, which are more compact, easier to process and more extensible than legacy JSON-based trace arguments. For the time being, we still support the old trace macros when V8 is embedded into Chrome and other embedders. Design doc: https://docs.google.com/document/d/1f7tt4cb-JcA5bQFR1oXk60ncJPpkL02_Hi_Bc6MfTQk/edit#heading=h.398p6b4eaen2 Bug: chromium:1006766 Change-Id: Ie71474fbe065821772b13d851487ebbca680c4ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947688 Commit-Queue: Sami Kyöstilä <skyostil@chromium.org> Auto-Submit: Sami Kyöstilä <skyostil@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#67217}
-
- 09 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the process: * Augment C++-generated Torque classes with SizeFor methods to calculate size of instances. * Add a new "@generateBodyDescriptor" annotation that causes Torque to generate C++ BodyDescriptors code that can be used to visit objects compatible with existing V8 mechanisms, e.g. GC * Fully automate C++ macro machinery so that adding non-extern Torque class doesn't require any C++ changes, including ensuring generation of instance types and proper boilerplate for validators and printers. * Make handling of @export a true annotation, allowing the modifier to be used on class declarations. * Add functionality such that classes with the @export annotation are available to be used from C++. Field accessors for exported classes are public and factory methods are generated to create instances of the objects from C++. * Change the Torque compiler such that Non-exported classes implicitly have the @generateBodyDescriptor annotation added and causes both verifiers and printers to be generated. * Switch non-extern Torque classes from using existing Struct-based machinery to being first-class classes that support more existing Torque class features. Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66621}
-
- 02 Mar, 2020 1 commit
-
-
Seth Brenith authored
This fixes a build break in certain configurations. v8_debug_helper depends on generate_bytecode_builtins_list via the following headers: In file included from gen/v8/tools/debug_helper/heap-constants-gen.cc:5: In file included from ../../v8\src/common/ptr-compr-inl.h:10: In file included from ../../v8\src/execution/isolate.h:19: In file included from ../../v8\src/builtins/builtins.h:9: Change-Id: I38e5d851afc6ce52716d3e5e64ae9219df396bd4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078768 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#66517}
-
- 16 Oct, 2019 1 commit
-
-
Seth Brenith authored
This change extends v8_debug_helper to export a new method that returns a list of all known heap object types. Why? We can substantially improve the user experience in our work-in- progress WinDbg extension if we register handlers not only for v8::internal::Object but for every specific HeapObject type. This has two benefits: - You save a click: if you're expanding a local variable of a more specific type than Object, you can see properties immediately rather than first needing to expand a sub-item that casts the variable to Object. - You retain the type hint: GetObjectProperties accepts a type hint string, and it's super important to pass it when working in a crash dump because the object's Map is probably inaccessible. If we have to cast to Object first, we lose this data. Bug: v8:9376 Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64331}
-
- 20 Sep, 2019 1 commit
-
-
Seth Brenith authored
If we can read an object's Map pointer but not any data from the Map itself, we may still be able to accurately describe the object's type if the Map pointer matches one of the known Maps from the snapshot. GetObjectProperties uses that data in one of two ways: - If it is sure that the Map pointer matches a known Map, then it uses the type from that Map and continues as if it read the type normally. - If the Map pointer is at the right offset within a heap page to match a known Map, but the caller didn't provide the addresses of the first pages in Map space or read-only space, then the type of that Map is just a guess and gets returned in a separate array. This gives the caller the opportunity to present guessed types to the user, and perhaps call again using the guessed type as the type hint. Bug: v8:9376 Change-Id: I187f67b77e76699863a14534a9d635b79f654124 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63908}
-
- 31 Jul, 2019 1 commit
-
-
Seth Brenith authored
This is a reland of 517ab73f 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/+/1717090Reviewed-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}
-
- 24 Jul, 2019 1 commit
-
-
Zhi An Ng authored
This reverts commit 517ab73f. Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538 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} TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9376 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#62899}
-
- 23 Jul, 2019 1 commit
-
-
Seth Brenith authored
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}
-