v8/test/mkgrokdump/mkgrokdump.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

223 lines
8.1 KiB
C++
Raw Normal View History

// Copyright 2012 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.
#include <stdio.h>
#include "include/libplatform/libplatform.h"
#include "include/v8.h"
#include "src/execution/frames.h"
#include "src/execution/isolate.h"
#include "src/heap/heap-inl.h"
#include "src/heap/paged-spaces-inl.h"
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
#include "src/heap/read-only-heap.h"
#include "src/heap/spaces.h"
#include "src/objects/objects-inl.h"
namespace v8 {
static const char* kHeader =
"# Copyright 2019 the V8 project authors. All rights reserved.\n"
"# Use of this source code is governed by a BSD-style license that can\n"
"# be found in the LICENSE file.\n"
"\n"
"# This file is automatically generated by mkgrokdump and should not\n"
"# be modified manually.\n"
"\n"
"# List of known V8 instance types.\n";
// Debug builds emit debug code, affecting code object sizes.
#ifndef DEBUG
static const char* kBuild = "shipping";
#else
static const char* kBuild = "non-shipping";
#endif
class MockArrayBufferAllocator : public v8::ArrayBuffer::Allocator {
public:
void* Allocate(size_t length) override { return nullptr; }
void* AllocateUninitialized(size_t length) override { return nullptr; }
void Free(void* p, size_t) override {}
};
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
static void DumpKnownMap(FILE* out, i::Heap* heap, const char* space_name,
i::HeapObject object) {
#define RO_ROOT_LIST_CASE(type, name, CamelName) \
if (root_name == nullptr && object == roots.name()) root_name = #CamelName;
#define MUTABLE_ROOT_LIST_CASE(type, name, CamelName) \
if (root_name == nullptr && object == heap->name()) root_name = #CamelName;
i::ReadOnlyRoots roots(heap);
const char* root_name = nullptr;
i::Map map = i::Map::cast(object);
intptr_t root_ptr =
static_cast<intptr_t>(map.ptr()) & (i::Page::kPageSize - 1);
READ_ONLY_ROOT_LIST(RO_ROOT_LIST_CASE)
MUTABLE_ROOT_LIST(MUTABLE_ROOT_LIST_CASE)
if (root_name == nullptr) return;
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
i::PrintF(out, " (\"%s\", 0x%05" V8PRIxPTR "): (%d, \"%s\"),\n", space_name,
root_ptr, map.instance_type(), root_name);
#undef MUTABLE_ROOT_LIST_CASE
#undef RO_ROOT_LIST_CASE
}
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
static void DumpKnownObject(FILE* out, i::Heap* heap, const char* space_name,
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
i::HeapObject object) {
#define RO_ROOT_LIST_CASE(type, name, CamelName) \
if (root_name == nullptr && object == roots.name()) { \
root_name = #CamelName; \
root_index = i::RootIndex::k##CamelName; \
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
}
#define ROOT_LIST_CASE(type, name, CamelName) \
if (root_name == nullptr && object == heap->name()) { \
root_name = #CamelName; \
root_index = i::RootIndex::k##CamelName; \
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
}
i::ReadOnlyRoots roots(heap);
const char* root_name = nullptr;
i::RootIndex root_index = i::RootIndex::kFirstSmiRoot;
intptr_t root_ptr = object.ptr() & (i::Page::kPageSize - 1);
STRONG_READ_ONLY_ROOT_LIST(RO_ROOT_LIST_CASE)
MUTABLE_ROOT_LIST(ROOT_LIST_CASE)
if (root_name == nullptr) return;
if (!i::RootsTable::IsImmortalImmovable(root_index)) return;
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
i::PrintF(out, " (\"%s\", 0x%05" V8PRIxPTR "): \"%s\",\n", space_name,
root_ptr, root_name);
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
#undef ROOT_LIST_CASE
#undef RO_ROOT_LIST_CASE
}
static void DumpSpaceFirstPageAddress(FILE* out, i::PagedSpace* space) {
const char* name = space->name();
i::Address first_page = reinterpret_cast<i::Address>(space->first_page());
i::Tagged_t compressed = i::CompressTagged(first_page);
uintptr_t unsigned_compressed = static_cast<uint32_t>(compressed);
i::PrintF(out, " 0x%08" V8PRIxPTR ": \"%s\",\n", unsigned_compressed, name);
}
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
static int DumpHeapConstants(FILE* out, const char* argv0) {
// Start up V8.
std::unique_ptr<v8::Platform> platform = v8::platform::NewDefaultPlatform();
v8::V8::InitializePlatform(platform.get());
v8::V8::Initialize();
v8::V8::InitializeExternalStartupData(argv0);
Isolate::CreateParams create_params;
MockArrayBufferAllocator mock_arraybuffer_allocator;
create_params.array_buffer_allocator = &mock_arraybuffer_allocator;
Isolate* isolate = Isolate::New(create_params);
{
Isolate::Scope scope(isolate);
i::Heap* heap = reinterpret_cast<i::Isolate*>(isolate)->heap();
i::ReadOnlyHeap* read_only_heap =
reinterpret_cast<i::Isolate*>(isolate)->read_only_heap();
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
i::PrintF(out, "%s", kHeader);
#define DUMP_TYPE(T) i::PrintF(out, " %d: \"%s\",\n", i::T, #T);
i::PrintF(out, "INSTANCE_TYPES = {\n");
INSTANCE_TYPE_LIST(DUMP_TYPE)
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
i::PrintF(out, "}\n");
#undef DUMP_TYPE
{
// Dump the KNOWN_MAP table to the console.
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
i::PrintF(out, "\n# List of known V8 maps.\n");
i::PrintF(out, "KNOWN_MAPS = {\n");
i::ReadOnlyHeapObjectIterator ro_iterator(read_only_heap);
for (i::HeapObject object = ro_iterator.Next(); !object.is_null();
object = ro_iterator.Next()) {
if (!object.IsMap()) continue;
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
DumpKnownMap(out, heap, i::Heap::GetSpaceName(i::RO_SPACE), object);
}
i::PagedSpaceObjectIterator iterator(heap, heap->map_space());
for (i::HeapObject object = iterator.Next(); !object.is_null();
object = iterator.Next()) {
if (!object.IsMap()) continue;
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
DumpKnownMap(out, heap, i::Heap::GetSpaceName(i::MAP_SPACE), object);
}
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
i::PrintF(out, "}\n");
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
}
{
// Dump the KNOWN_OBJECTS table to the console.
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
i::PrintF(out, "\n# List of known V8 objects.\n");
i::PrintF(out, "KNOWN_OBJECTS = {\n");
i::ReadOnlyHeapObjectIterator ro_iterator(read_only_heap);
for (i::HeapObject object = ro_iterator.Next(); !object.is_null();
object = ro_iterator.Next()) {
// Skip read-only heap maps, they will be reported elsewhere.
if (object.IsMap()) continue;
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
DumpKnownObject(out, heap, i::Heap::GetSpaceName(i::RO_SPACE), object);
}
i::PagedSpaceIterator spit(heap);
for (i::PagedSpace* s = spit.Next(); s != nullptr; s = spit.Next()) {
i::PagedSpaceObjectIterator it(heap, s);
// Code objects are generally platform-dependent.
if (s->identity() == i::CODE_SPACE || s->identity() == i::MAP_SPACE)
continue;
const char* sname = s->name();
for (i::HeapObject o = it.Next(); !o.is_null(); o = it.Next()) {
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
DumpKnownObject(out, heap, sname, o);
}
}
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
i::PrintF(out, "}\n");
}
if (COMPRESS_POINTERS_BOOL) {
// Dump a list of addresses for the first page of each space that contains
// objects in the other tables above. This is only useful if two
// assumptions hold:
// 1. Those pages are positioned deterministically within the heap
// reservation block during snapshot deserialization.
// 2. Those pages cannot ever be moved (such as by compaction).
i::PrintF(out,
"\n# Lower 32 bits of first page addresses for various heap "
"spaces.\n");
i::PrintF(out, "HEAP_FIRST_PAGES = {\n");
i::PagedSpaceIterator it(heap);
for (i::PagedSpace* s = it.Next(); s != nullptr; s = it.Next()) {
// Code page is different on Windows vs Linux (bug v8:9844), so skip it.
if (s->identity() == i::CODE_SPACE) {
continue;
}
DumpSpaceFirstPageAddress(out, s);
}
DumpSpaceFirstPageAddress(out, read_only_heap->read_only_space());
i::PrintF(out, "}\n");
}
// Dump frame markers
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
i::PrintF(out, "\n# List of known V8 Frame Markers.\n");
#define DUMP_MARKER(T, class) i::PrintF(out, " \"%s\",\n", #T);
i::PrintF(out, "FRAME_MARKERS = (\n");
STACK_FRAME_TYPE_LIST(DUMP_MARKER)
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
i::PrintF(out, ")\n");
#undef DUMP_MARKER
}
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
i::PrintF(out, "\n# This set of constants is generated from a %s build.\n",
kBuild);
// Teardown.
isolate->Dispose();
v8::V8::ShutdownPlatform();
return 0;
}
} // namespace v8
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
int main(int argc, char* argv[]) {
FILE* out = stdout;
if (argc > 2 && strcmp(argv[1], "--outfile") == 0) {
out = fopen(argv[2], "wb");
}
return v8::DumpHeapConstants(out, argv[0]);
}