1. 16 Mar, 2020 2 commits
    • Clemens Backes's avatar
      [wasm] Load register values from DebugBreak frame · ae03752f
      Clemens Backes authored
      This implements inspection of live registers on breakpoints in Liftoff.
      To that end, the frame pointer of the WasmDebugBreak frame is remembered
      when iterating the stack. Based on a platform-specific implementation of
      {WasmDebugBreakFrameConstants}, the offset of the respective register
      within that frame is computed, and the value is read from the frame.
      
      As a drive-by, the wasm debug side table is storing register codes as
      liftoff codes, which can also store register pairs (needed for i64 on
      32-bit platforms, and for SIMD, which is not supported yet).
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I01b669baf56430e100cd46cc46f210121ea679da
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102574Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66719}
      ae03752f
    • Clemens Backes's avatar
      [wasm] Fix registers spilled in DebugBreak frame · e47f9a9d
      Clemens Backes authored
      The set of registers to spill was wrong. Instead of spilling wasm
      parameter registers (like the WasmCompileLazy builtin), we should spill
      all registers that are being used as Liftoff cache registers.
      This CL defines platform-specific WasmDebugBreakFrameConstants which
      hold the set of registers to spill. This set is used in the builtin, and
      will later be used for inspecting the spilled registers.
      
      In order to iterate bit sets more easily in both direction (MSB to LSB
      or LSB to MSB), we add a base::bits::IterateBits{,Backwards} method
      which provides the respective iterators.
      
      R=jkummerow@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10222
      Change-Id: I73ecbdff9b29e244c478b404063c0c9ee25bc821
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2102570Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66715}
      e47f9a9d
  2. 25 Oct, 2019 2 commits
  3. 28 May, 2019 1 commit
  4. 22 May, 2019 1 commit
  5. 15 Mar, 2019 1 commit
  6. 15 Feb, 2019 1 commit
  7. 17 Jan, 2019 1 commit
  8. 10 Jan, 2019 1 commit
    • tzik's avatar
      Shuffle the parameter ordering of JSEntry · 7efa02a3
      tzik authored
      This moves |root_register_value| parameter of JSEntryFunction to the
      first. I.e. the type of entry function will be changed from
       Object*(Object* new_target, Object* target, Object* receiver,
               int argc, Object*** args,
               Address root_register_value)
      to
       Object*(Address root_register_value,
               Object* new_target, Object* target, Object* receiver,
               int argc, Object*** args),
      and moves all parameter handling except for |root_register_value| from
      JSEntryVariant to JSEntryTrampolineHelper.
      
      This is a preparation to add another JS entry point for RunMicrotasks,
      whose type will be
       Object*(Address root_register_value, MicrotaskQueue*).
      The new entry point requires |root_register_value| to be the first to
      share the implementation of the EntryFrame setup with existing ones.
      
      Bug: v8:8124
      Change-Id: I675376a2ccd240f61cf04eea6fe9a91031e06ede
      Reviewed-on: https://chromium-review.googlesource.com/c/1372857
      Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#58683}
      7efa02a3
  9. 06 Dec, 2018 1 commit
  10. 09 Oct, 2018 1 commit
  11. 19 Jun, 2018 1 commit
  12. 29 May, 2018 1 commit
  13. 10 Apr, 2018 1 commit
  14. 02 Feb, 2018 1 commit
  15. 03 Aug, 2017 1 commit
  16. 01 Aug, 2017 1 commit
  17. 08 Mar, 2016 1 commit
    • danno's avatar
      [runtime] Unify and simplify how frames are marked · 9dcd0857
      danno authored
      Before this CL, various code stubs used different techniques
      for marking their frames to enable stack-crawling and other
      access to data in the frame. All of them were based on a abuse
      of the "standard" frame representation, e.g. storing the a
      context pointer immediately below the frame's fp, and a
      function pointer after that. Although functional, this approach
      tends to make stubs and builtins do an awkward, unnecessary
      dance to appear like standard frames, even if they have
      nothing to do with JavaScript execution.
      
      This CL attempts to improve this by:
      
      * Ensuring that there are only two fundamentally different
        types of frames, a "standard" frame and a "typed" frame.
        Standard frames, as before, contain both a context and
        function pointer. Typed frames contain only a minimum
        of a smi marker in the position immediately below the fp
        where the context is in standard frames.
      * Only interpreted, full codegen, and optimized Crankshaft and
        TurboFan JavaScript frames use the "standard" format. All
        other frames use the type frame format with an explicit
        marker.
      * Typed frames can contain one or more values below the
        type marker. There is new magic macro machinery in
        frames.h that simplifies defining the offsets of these fields
        in typed frames.
      * A new flag in the CallDescriptor enables specifying whether
        a frame is a standard frame or a typed frame. Secondary
        register location spilling is now only enabled for standard
        frames.
      * A zillion places in the code have been updated to deal with
        the fact that most code stubs and internal frames use the
        typed frame format. This includes changes in the
        deoptimizer, debugger, and liveedit.
      * StandardFrameConstants::kMarkerOffset is deprecated,
        (CommonFrameConstants::kContextOrFrameTypeOffset
        and StandardFrameConstants::kFrameOffset are now used
        in its stead).
      
      LOG=N
      
      Review URL: https://codereview.chromium.org/1696043002
      
      Cr-Commit-Position: refs/heads/master@{#34571}
      9dcd0857
  18. 25 Feb, 2016 1 commit
  19. 30 Sep, 2015 1 commit
  20. 22 Sep, 2015 1 commit
    • bmeurer's avatar
      [builtins] Add support for NewTarget to Execution::New. · 1dfac69f
      bmeurer authored
      Introduce new builtins Construct and ConstructFunction (in line
      with the Call and CallFunction builtins that we already have) as
      proper bottleneck for Construct and [[Construct]] on JSFunctions.
      Use these builtins to support passing NewTarget from C++ to
      JavaScript land.
      
      Long-term we want the CallConstructStub to be used for
      gathering feedback on entry to construction chain (i.e. the
      initial new Foo), and use the Construct builtins to do the
      actual work inside the construction chain (i.e. calling into
      super and stuff).
      
      MIPS and MIPS64 ports contributed by akos.palfi@imgtec.com.
      
      R=jarin@chromium.org
      BUG=v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1359583002
      
      Cr-Commit-Position: refs/heads/master@{#30857}
      1dfac69f
  21. 13 Jul, 2015 1 commit
  22. 07 Jul, 2015 1 commit
  23. 25 Jun, 2015 1 commit
  24. 10 Mar, 2015 1 commit
  25. 20 May, 2014 1 commit
  26. 29 Apr, 2014 1 commit
  27. 12 Mar, 2014 1 commit
  28. 11 Mar, 2014 2 commits
  29. 07 Jan, 2014 1 commit
  30. 30 Jul, 2013 1 commit
  31. 08 Apr, 2013 1 commit
  32. 06 Mar, 2013 1 commit
  33. 05 Feb, 2013 1 commit
  34. 12 Jun, 2012 1 commit
  35. 24 Jan, 2012 1 commit
  36. 29 Nov, 2011 1 commit
  37. 11 Nov, 2011 1 commit