1. 19 Jan, 2021 1 commit
    • Seth Brenith's avatar
      [arm][arm64] Use normal fp semantics in JSEntry · a016c9fe
      Seth Brenith authored
      On arm64, Windows Performance Recorder gets confused by the fact that fp
      in Builtins_JSEntry doesn't point to the saved {fp, lr} pair for the
      caller frame. The expected usage of fp is documented in [1]:
      
        The frame pointer (x29) is required for compatibility with fast stack
        walking used by ETW and other services. It must point to the previous
        {x29, x30} pair on the stack.
      
      In slightly more detail, the Windows function RtlWalkFrameChain is
      responsible for generating stack traces during profiling with Windows
      Performance Recorder, and that function relies on the rule quoted above.
      Notably, it does not make any effort to read the unwinding data that one
      could obtain with RtlLookupFunctionEntry. Stack walks using that data,
      such as those performed by WinDbg and the cctest StackUnwindingWin64,
      work fine.
      
      It would be convenient if we could use fp in a more standard way during
      JSEntry so that Windows profiling tools work correctly. (We can also
      reduce JSEntry by two instructions in doing so.)
      
      Both arm and arm64 currently put a -1 value on the stack at the location
      that fp points to. This could prevent accidental access during the
      epilog of JSEntry, where fp might be zero. However, we believe that this
      protection is no longer necessary, and any bug that causes a read from
      fp during the end of JSEntry would cause various CQ failures.
      
      [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160
      
      Change-Id: Iece5666129b9188fc4c12007809b50f046f4044f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2607636
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72165}
      a016c9fe
  2. 20 Oct, 2020 1 commit