Commit Graph

5 Commits

Author SHA1 Message Date
Tobias Tebbi
21b585165f Reland "[torque] refactor: use -tq only in filenames derived from .tq files"
This is a reland of 64caf2b0b2

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 15:04:18 +00:00
Francis McCabe
92aaace1a9 Revert "[torque] refactor: use -tq only in filenames derived from .tq files"
This reverts commit 64caf2b0b2.

Reason for revert: Seems to be causing a failure:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?

Original change's description:
> [torque] refactor: use -tq only in filenames derived from .tq files
> 
> This is to establish a naming rule for Torque-generated files:
> - If the file is called foo/bar-tq..., then it is derived from a
>   file foo/bar.tq
> - Otherwise it doesn't belong to a specific .tq file.
> 
> So far, we attached -tq to all Torque-generated file names, where it
> sometimes corresponded to a .tq file name and sometimes not.
> It is not necessary to add -tq to file names to indicate that they are
> Torque-generated, since they are already in a directory called
> torque-generated, and we always refer to them as
> "torque-generated/filename", so there is no confusion even though some
> files now have the same name as a corresponding hand-written file, for
> example factory.cc.
> 
> TBR: hpayer@chromium.org
> Bug: v8:7793
> Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70060}

TBR=jgruber@chromium.org,tebbi@chromium.org

Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486
Reviewed-by: Francis McCabe <fgm@chromium.org>
Commit-Queue: Francis McCabe <fgm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70065}
2020-09-22 17:20:30 +00:00
Tobias Tebbi
64caf2b0b2 [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}
2020-09-22 15:52:58 +00:00
Seth Brenith
8b1a5681de [tools] Fix v8windbg behavior on Map's bit_field2
Bill kindly pointed out to me that v8windbg was not handling bit_field2
correctly. The issue was that the constexpr type for ElementsKind was,
somewhat unsurprisingly, "ElementsKind", but v8windbg expected a fully-
qualified type name like "v8::internal::ElementsKind". This change
addresses the problem in two ways:
1. Update v8windbg's type resolution logic to resolve type names as if
   they were used in the v8::internal namespace. This makes it more
   consistent with how those type names are used in other generated
   Torque code, reducing surprises and the number of times we have to
   write `v8::internal::` in .tq files.
2. Add compile-time verification that any constexpr type name used as a
   string in class-debug-readers-tq.cc can also resolve as a type name.

Bug: v8:9376
Change-Id: I349cd6ab586fd8345a1fa8bfc3989bb8e6376ab8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2063769
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#66633}
2020-03-09 17:36:27 +00:00
Seth Brenith
4d0360aa84 [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-10-16 15:35:18 +00:00