e7d8e978b9
7 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Seth Brenith
|
8b1a5681de |
[tools] Fix v8windbg behavior on Map's bit_field2
Bill kindly pointed out to me that v8windbg was not handling bit_field2 correctly. The issue was that the constexpr type for ElementsKind was, somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully- qualified type name like "v8::internal::ElementsKind". This change addresses the problem in two ways: 1. Update v8windbg's type resolution logic to resolve type names as if they were used in the v8::internal namespace. This makes it more consistent with how those type names are used in other generated Torque code, reducing surprises and the number of times we have to write `v8::internal::` in .tq files. 2. Add compile-time verification that any constexpr type name used as a string in class-debug-readers-tq.cc can also resolve as a type name. Bug: v8:9376 Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66633} |
||
|
Seth Brenith
|
534482b35b |
[tools] Show contents of cached external strings from crash dumps
This change adds support for the postmortem inspection library to show the content of cached external strings if that content is available. It also fixes a minor annoyance where strings with unavailable data would show up as "...". Now, if fetching the very first character fails, we omit the literal value from the output. Bug: v8:9376 Change-Id: Id694a774c231ab3467fb59b1c149284729acfb20 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1987922 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65961} |
||
|
Seth Brenith
|
1d3c4975be |
[tools] Use instance types of known Maps in v8_debug_helper
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} |
||
|
Seth Brenith
|
0a31d508f1 |
[tools] Teach v8_debug_helper where heap spaces start in ptr-compr mode
v8_debug_helper attempts to flag known object pointers when it can recognize them, even if the memory pointed to is not available in the crash dump. In ptr-compr builds, the first pages of the map space, read-only space, and old space are always at the same offsets within the heap reservation region, so we can more easily detect known objects. Bug: v8:9376 Change-Id: I04e0d2357143d753f575f556e94f8fd42ce9d811 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783729 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#63624} |
||
|
Seth Brenith
|
0921e8f28b |
Reland "Add postmortem debugging helper library"
This is a reland of
|
||
Zhi An Ng
|
6747e3a186 |
Revert "Add postmortem debugging helper library"
This reverts commit
|
||
|
Seth Brenith
|
517ab73fd7 |
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} |