1. 23 Jun, 2020 1 commit
  2. 12 May, 2020 1 commit
    • Omer Katz's avatar
      heap,cppgc: Update StackState enum values · fff219bf
      Omer Katz authored
      This CL adds 2 new values to the EmbedderStackState enum with more
      explicit names. The old values are updated as aliases to the new
      values and marked as soon to be deprecated. This CL also moves the
      enum to v8-platform.h so that it can be reused by cppgc.
      
      Depracating individual values in an enum is supported by GCC only
      since version 6. Thus new macros were needed for the deprecation
      (which delegate to the existing macros when supported). GCC versions
      older than 6 are still used by the CQ bots.
      
      Bug: chromium:1056170
      Change-Id: Id1ea73edfbbae282b0d8a3bb103dbbbf8ebd417e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188971
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67744}
      fff219bf
  3. 06 May, 2020 1 commit
  4. 17 Apr, 2020 1 commit
  5. 09 Mar, 2020 2 commits
    • Seth Brenith's avatar
      [tools] Fix v8windbg behavior on Map's bit_field2 · 8b1a5681
      Seth Brenith authored
      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/+/2063769Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66633}
      8b1a5681
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored
      In the process:
      
      * Augment C++-generated Torque classes with SizeFor methods to
        calculate size of instances.
      
      * Add a new "@generateBodyDescriptor" annotation that causes Torque to
        generate C++ BodyDescriptors code that can be used to visit objects
        compatible with existing V8 mechanisms, e.g. GC
      
      * Fully automate C++ macro machinery so that adding non-extern Torque
        class doesn't require any C++ changes, including ensuring generation
        of instance types and proper boilerplate for validators and
        printers.
      
      * Make handling of @export a true annotation, allowing the modifier to
        be used on class declarations.
      
      * Add functionality such that classes with the @export annotation are
        available to be used from C++. Field accessors for exported classes
        are public and factory methods are generated to create instances of
        the objects from C++.
      
      * Change the Torque compiler such that Non-exported classes implicitly
        have the @generateBodyDescriptor annotation added and causes both
        verifiers and printers to be generated.
      
      * Switch non-extern Torque classes from using existing Struct-based
        machinery to being first-class classes that support more existing
        Torque class features.
      
      Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  6. 02 Mar, 2020 1 commit
    • Seth Brenith's avatar
      [tools] include missing dep for v8_debug_helper · 5f5bcace
      Seth Brenith authored
      This fixes a build break in certain configurations. v8_debug_helper
      depends on generate_bytecode_builtins_list via the following headers:
      
      In file included from gen/v8/tools/debug_helper/heap-constants-gen.cc:5:
      In file included from ../../v8\src/common/ptr-compr-inl.h:10:
      In file included from ../../v8\src/execution/isolate.h:19:
      In file included from ../../v8\src/builtins/builtins.h:9:
      
      Change-Id: I38e5d851afc6ce52716d3e5e64ae9219df396bd4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2078768
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66517}
      5f5bcace
  7. 23 Jan, 2020 1 commit
  8. 07 Jan, 2020 1 commit
  9. 26 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Add in-object properties to debug_helper · dcb828b4
      Seth Brenith authored
      Until now, the in-object properties on JSObject have been invisible to
      tools using the postmortem debugging library. With this change, those
      tools will get enough information to show a flat list of property
      values. This is still less powerful than the runtime printers, which can
      show the corresponding key for each value, but it's a big step up from
      manually inspecting memory.
      
      This change basically requires a reimplementation of
      Map::GetInObjectProperties for postmortem debugging. I'm not
      enthusiastic about duplicating this logic, but it's pretty small and I
      don't see any good alternatives.
      
      As a drive-by cleanup, I moved some inline string literals into a batch
      of constexpr char arrays.
      
      Bug: v8:9376
      Change-Id: Ia24c05f6e823086babaa07882d0d320ab9a225db
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1930174Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65183}
      dcb828b4
  10. 20 Nov, 2019 1 commit
    • Seth Brenith's avatar
      [torque][tools] Define layout of DescriptorArray for postmortem tools · 6b11b700
      Seth Brenith authored
      This change defines a way that v8_debug_helper can describe object
      fields which are packed structs, and uses it for the "descriptors" field
      in DescriptorArray.
      
      In more detail:
      - debug-helper.h (the public interface for v8_debug_helper) adds a size
        and an optional list of struct properties to ObjectProperty.
      - debug-helper-internal.h mirrors those changes to the internal class
        hierarchy which maintains proper unique_ptr ownership.
      - In src/torque/class-debug-reader-generator.cc,
        - Some existing logic is moved into smaller functions.
        - New logic is added to generate the field list for structs. Example
          output is included in a comment above the function
          GenerateGetPropsChunkForField.
      
      Bug: v8:9376
      Change-Id: I531acac039ccb42050641448a4cbaec26186a7bc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1894362
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65079}
      6b11b700
  11. 28 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use generated instance types, part 1 · 91e6421c
      Seth Brenith authored
      This change begins making use of the fact that Torque now knows about
      the relationship between classes and instance types, to replace a few
      repetitive lists:
      
      - Instance type checkers (single and range), defined in
        src/objects/instance-type.h
      - Verification dispatch in src/diagnostics/objects-debug.cc
      - Printer dispatch in src/diagnostics/objects-printer.cc
      - Postmortem object type detection in
        tools/debug_helper/get-object-properties.cc
      
      Torque is updated to generate four macro lists for the instance types,
      representing all of the classes separated in two dimensions: classes
      that correspond to a single instance type versus those that have a
      range, and classes that are fully defined in Torque (with fields and
      methods inside '{}') versus those that are only declared. The latter
      distinction is useful because fully-defined classes are guaranteed to
      correspond to real C++ classes, whereas only-declared classes are not.
      
      A few other changes were required to make the lists above work:
      
      - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
        and avoid conflicts with the new macro-generated IsFiller method. This
        is the part I'm most worried about: I think the new name is an
        improvement for clarity and consistency, but I could imagine someone
        typing IsFiller out of habit and introducing a bug. If we'd prefer to
        keep the name IsFiller, my other idea is to rename FreeSpace to
        VariableSizeFiller and Filler to FixedSizeFiller.
      - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
        expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
      - Normalized the dispatched behavior for BigIntBase and HeapNumber.
      - Added a few new object printers.
      
      Bug: v8:7793
      Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64597}
      91e6421c
  12. 16 Oct, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Add list of classes to v8_debug_helper · 4d0360aa
      Seth Brenith authored
      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/+/1822859Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#64331}
      4d0360aa
  13. 15 Oct, 2019 1 commit
  14. 09 Oct, 2019 1 commit
  15. 20 Sep, 2019 1 commit
    • Seth Brenith's avatar
      [tools] Use instance types of known Maps in v8_debug_helper · 1d3c4975
      Seth Brenith authored
      If we can read an object's Map pointer but not any data from the Map
      itself, we may still be able to accurately describe the object's type if
      the Map pointer matches one of the known Maps from the snapshot.
      GetObjectProperties uses that data in one of two ways:
      - If it is sure that the Map pointer matches a known Map, then it uses
        the type from that Map and continues as if it read the type normally.
      - If the Map pointer is at the right offset within a heap page to match
        a known Map, but the caller didn't provide the addresses of the first
        pages in Map space or read-only space, then the type of that Map is
        just a guess and gets returned in a separate array. This gives the
        caller the opportunity to present guessed types to the user, and
        perhaps call again using the guessed type as the type hint.
      
      Bug: v8:9376
      Change-Id: I187f67b77e76699863a14534a9d635b79f654124
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787986
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63908}
      1d3c4975
  16. 13 Sep, 2019 1 commit
  17. 10 Sep, 2019 1 commit
  18. 09 Sep, 2019 1 commit
  19. 30 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [tools][torque] Include string values in GetObjectProperties responses · 2ccca6c5
      Seth Brenith authored
      This change provides a quick way to see string contents in postmortem
      debugging sessions, without digging through a (possibly very large, in
      the case of ConsString) tree of properties. As well as being convenient
      for inspecting String objects, this functionality will also be necessary
      for displaying property names on JSReceiver objects. In order to support
      custom behaviors for specific classes, this change extends the existing
      generated debug reader classes with a visitor pattern.
      
      Bug: v8:9376
      Change-Id: I70eab9ea4e74ca0fab39bf5998d6a602716a4202
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771939Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63485}
      2ccca6c5
  20. 22 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [tools][torque]Improve postmortem API behavior on strings · 1a815e44
      Seth Brenith authored
      This change adds the indexed field for the characters in the definition
      of sequential string types, and introduces support for recognizing the
      various specific string types in v8_debug_helper. In an attempt to
      avoid duplicating info about string instance types, it also refactors
      String::Get so that StringShape (a simple class usable by postmortem
      tools) can dispatch using a class that defines behaviors for each
      concrete type.
      
      Bug: v8:9376
      Change-Id: Id0653040f6decddc004c73f8fe93d2187828c2c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735795
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63352}
      1a815e44
  21. 31 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Reland "Add postmortem debugging helper library" · 0921e8f2
      Seth Brenith authored
      This is a reland of 517ab73f
      
      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/+/1717090Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63008}
      0921e8f2
  22. 24 Jul, 2019 1 commit
    • Zhi An Ng's avatar
      Revert "Add postmortem debugging helper library" · 6747e3a1
      Zhi An Ng authored
      This reverts commit 517ab73f.
      
      Reason for revert: Test failures https://bugs.chromium.org/p/v8/issues/detail?id=9538
      
      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}
      
      TBR=yangguo@chromium.org,mvstanton@chromium.org,jgruber@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: Ia078f2e8d101d2375b5db88021b2d65d28f1b075
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9376
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716033Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62899}
      6747e3a1
  23. 23 Jul, 2019 1 commit
    • Seth Brenith's avatar
      Add postmortem debugging helper library · 517ab73f
      Seth Brenith authored
      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: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62882}
      517ab73f