AuroraMiddleware/v8
1
0
Fork 0
Code Issues 2 Pull Requests Releases Wiki Activity
bfea0fda88
v8/tools/debug_helper/list-object-classes.cc

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

16 lines
438 B
C++
Raw Normal View History

[tools] Add list of classes to v8_debug_helper This change extends v8_debug_helper to export a new method that returns a list of all known heap object types. Why? We can substantially improve the user experience in our work-in- progress WinDbg extension if we register handlers not only for v8::internal::Object but for every specific HeapObject type. This has two benefits: - You save a click: if you're expanding a local variable of a more specific type than Object, you can see properties immediately rather than first needing to expand a sub-item that casts the variable to Object. - You retain the type hint: GetObjectProperties accepts a type hint string, and it's super important to pass it when working in a crash dump because the object's Map is probably inaccessible. If we have to cast to Object first, we lose this data. Bug: v8:9376 Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64331}
2019-09-26 23:15:01 +00:00
// Copyright 2019 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 "debug-helper-internal.h"
Reland "[torque] refactor: use -tq only in filenames derived from .tq files" This is a reland of 64caf2b0b26cb6c955fbbb81365ac54820de51a0 Original change's description: > [torque] refactor: use -tq only in filenames derived from .tq files > > This is to establish a naming rule for Torque-generated files: > - If the file is called foo/bar-tq..., then it is derived from a > file foo/bar.tq > - Otherwise it doesn't belong to a specific .tq file. > > So far, we attached -tq to all Torque-generated file names, where it > sometimes corresponded to a .tq file name and sometimes not. > It is not necessary to add -tq to file names to indicate that they are > Torque-generated, since they are already in a directory called > torque-generated, and we always refer to them as > "torque-generated/filename", so there is no confusion even though some > files now have the same name as a corresponding hand-written file, for > example factory.cc. > > TBR: hpayer@chromium.org > Bug: v8:7793 > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70060} Bug: v8:7793 TBR: hpayer@chromium.org jgruber@chromium.org Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70137}
2020-09-25 14:11:33 +00:00
#include "torque-generated/class-debug-readers.h"
[tools] Add list of classes to v8_debug_helper This change extends v8_debug_helper to export a new method that returns a list of all known heap object types. Why? We can substantially improve the user experience in our work-in- progress WinDbg extension if we register handlers not only for v8::internal::Object but for every specific HeapObject type. This has two benefits: - You save a click: if you're expanding a local variable of a more specific type than Object, you can see properties immediately rather than first needing to expand a sub-item that casts the variable to Object. - You retain the type hint: GetObjectProperties accepts a type hint string, and it's super important to pass it when working in a crash dump because the object's Map is probably inaccessible. If we have to cast to Object first, we lose this data. Bug: v8:9376 Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64331}
2019-09-26 23:15:01 +00:00
[tools] Fix v8windbg behavior on Map's bit_field2 Bill kindly pointed out to me that v8windbg was not handling bit_field2 correctly. The issue was that the constexpr type for ElementsKind was, somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully- qualified type name like "v8::internal::ElementsKind". This change addresses the problem in two ways: 1. Update v8windbg's type resolution logic to resolve type names as if they were used in the v8::internal namespace. This makes it more consistent with how those type names are used in other generated Torque code, reducing surprises and the number of times we have to write `v8::internal::` in .tq files. 2. Add compile-time verification that any constexpr type name used as a string in class-debug-readers-tq.cc can also resolve as a type name. Bug: v8:9376 Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#66633}
2020-02-27 18:14:53 +00:00
namespace di = v8::internal::debug_helper_internal;
[tools] Add list of classes to v8_debug_helper This change extends v8_debug_helper to export a new method that returns a list of all known heap object types. Why? We can substantially improve the user experience in our work-in- progress WinDbg extension if we register handlers not only for v8::internal::Object but for every specific HeapObject type. This has two benefits: - You save a click: if you're expanding a local variable of a more specific type than Object, you can see properties immediately rather than first needing to expand a sub-item that casts the variable to Object. - You retain the type hint: GetObjectProperties accepts a type hint string, and it's super important to pass it when working in a crash dump because the object's Map is probably inaccessible. If we have to cast to Object first, we lose this data. Bug: v8:9376 Change-Id: I4d635a1826574a3d08ac657e848e1fe7b83849fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822859 Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64331}
2019-09-26 23:15:01 +00:00
extern "C" {
V8_DEBUG_HELPER_EXPORT const d::ClassList*
_v8_debug_helper_ListObjectClasses() {
return &di::kObjectClassList;
}
}
Reference in New Issue Copy Permalink