v8/test/mkgrokdump/mkgrokdump.cc

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

244 lines
8.7 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"
Reland "[include] Split out v8.h" This is a reland of d1b27019d3bf86360ea838c317f8505fac6d3a7e Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629 Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
2021-08-23 13:01:06 +00:00
#include "include/v8-array-buffer.h"
#include "include/v8-initialization.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/safepoint.h"
#include "src/heap/spaces.h"
#include "src/objects/objects-inl.h"
namespace v8 {
static const char* kHeader =
"#!/usr/bin/env python3\n"
"# 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"
"# yapf: disable\n\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;
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
}
Reland "[heap] Make ReadOnlySpace use bump pointer allocation" This reverts commit f78d69fa5da7f9a0415e8bb863718d237d9f5e30. With https://chromium-review.googlesource.com/c/v8/v8/+/2243216, incorrect MemoryChunk::FromHeapObject uses are now fixed. Original change's description: > Revert "[heap] Make ReadOnlySpace use bump pointer allocation" > > This reverts commit 81c34968a7857bc1515a6381ffa997e69269b294 and also > 490f3580a352d2c1cd07c2b2d280d292dcd1da92 which depends on the former. > > Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438 > Original change's description: > > [heap] Make ReadOnlySpace use bump pointer allocation > > > > This changes ReadOnlySpace to no longer be a PagedSpace but instead it > > is now a BaseSpace. BasicSpace is a new base class that Space inherits > > from and which has no allocation methods and does not dictate how the > > pages should be held. > > > > ReadOnlySpace unlike Space holds its pages as a > > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses > > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and > > cannot be held in a heap::List. This is desirable since with pointer > > compression we would like to remap these pages to different memory > > addresses which would be impossible with a heap::List. > > > > Since ReadOnlySpace no longer uses most of the code from the other > > Spaces it makes sense to simplify its memory allocation to use a simple > > bump pointer and always allocate a new page whenever an allocation > > exceeds the remaining space on the final page. > > > > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060 > > Commit-Queue: Dan Elphick <delphick@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#68137} > > TBR=ulan@chromium.org,delphick@chromium.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68211} TBR=ulan@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254 Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68407}
2020-06-18 10:36:32 +00:00
static void DumpSpaceFirstPageAddress(FILE* out, i::BaseSpace* space,
i::Address first_page) {
const char* name = space->name();
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 "[heap] Make ReadOnlySpace use bump pointer allocation" This reverts commit f78d69fa5da7f9a0415e8bb863718d237d9f5e30. With https://chromium-review.googlesource.com/c/v8/v8/+/2243216, incorrect MemoryChunk::FromHeapObject uses are now fixed. Original change's description: > Revert "[heap] Make ReadOnlySpace use bump pointer allocation" > > This reverts commit 81c34968a7857bc1515a6381ffa997e69269b294 and also > 490f3580a352d2c1cd07c2b2d280d292dcd1da92 which depends on the former. > > Reason for revert: Break CFI tests in chromium https://ci.chromium.org/p/chromium/builders/ci/Linux%20CFI/17438 > Original change's description: > > [heap] Make ReadOnlySpace use bump pointer allocation > > > > This changes ReadOnlySpace to no longer be a PagedSpace but instead it > > is now a BaseSpace. BasicSpace is a new base class that Space inherits > > from and which has no allocation methods and does not dictate how the > > pages should be held. > > > > ReadOnlySpace unlike Space holds its pages as a > > std::vector<ReadOnlyPage>, where ReadOnlyPage directly subclasses > > BasicMemoryChunk, meaning they do not have prev_ and next_ pointers and > > cannot be held in a heap::List. This is desirable since with pointer > > compression we would like to remap these pages to different memory > > addresses which would be impossible with a heap::List. > > > > Since ReadOnlySpace no longer uses most of the code from the other > > Spaces it makes sense to simplify its memory allocation to use a simple > > bump pointer and always allocate a new page whenever an allocation > > exceeds the remaining space on the final page. > > > > Change-Id: Iee6d9f96cfb174b4026ee671ee4f897909b38418 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2209060 > > Commit-Queue: Dan Elphick <delphick@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#68137} > > TBR=ulan@chromium.org,delphick@chromium.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Change-Id: I68c9834872e55eb833be081f8ff99b786bfa9894 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2232552 > Commit-Queue: Dan Elphick <delphick@chromium.org> > Reviewed-by: Dan Elphick <delphick@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68211} TBR=ulan@chromium.org,delphick@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: Id5b3cce41b5dec1dca816c05848d183790b1cc05 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250254 Reviewed-by: Dan Elphick <delphick@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68407}
2020-06-18 10:36:32 +00:00
template <typename SpaceT>
static void DumpSpaceFirstPageAddress(FILE* out, SpaceT* space) {
i::Address first_page = space->FirstPageAddress();
DumpSpaceFirstPageAddress(out, space, first_page);
}
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 Sandbox rebranding This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981 Reviewed-by: Hannes Payer <hpayer@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
2021-12-15 13:39:15 +00:00
#ifdef V8_SANDBOX
if (!v8::V8::InitializeSandbox()) {
FATAL("Could not initialize the sandbox");
}
#endif
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::SafepointScope safepoint_scope(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;
DumpKnownMap(out, heap, i::BaseSpace::GetSpaceName(i::RO_SPACE),
object);
}
i::PagedSpace* space_for_maps = heap->space_for_maps();
i::PagedSpaceObjectIterator iterator(heap, space_for_maps);
for (i::HeapObject object = iterator.Next(); !object.is_null();
object = iterator.Next()) {
if (!object.IsMap()) continue;
DumpKnownMap(out, heap, space_for_maps->name(), 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;
DumpKnownObject(out, heap, i::BaseSpace::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::Dispose();
v8::V8::DisposePlatform();
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]);
}