[all-commits] [llvm/llvm-project] bbd54e: Reapply "[lldb/aarch64] Fix unwinding when signal ...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: bbd54e08b08f5ccd38c4665178e65c58f7b14459
      https://github.com/llvm/llvm-project/commit/bbd54e08b08f5ccd38c4665178e65c58f7b14459
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2024-05-21 (Tue, 21 May 2024)

  Changed paths:
    M lldb/source/Plugins/Instruction/ARM64/EmulateInstructionARM64.cpp
    M lldb/source/Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.cpp
    M lldb/source/Target/RegisterContextUnwind.cpp
    M lldb/test/API/functionalities/bt-interrupt/main.c
    A lldb/test/Shell/Unwind/Inputs/signal-in-leaf-function-aarch64.c
    A lldb/test/Shell/Unwind/signal-in-leaf-function-aarch64.test
    M lldb/unittests/UnwindAssembly/ARM64/TestArm64InstEmulation.cpp

  Log Message:
  -----------
  Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (#92503)

…unction (#91321)"

This reapplies fd1bd53ba5a06f344698a55578f6a5d79c457e30, which was
reverted due to a test failure on aarch64/windows. The failure was
caused by a combination of several factors:
- clang targeting aarch64-windows (unlike msvc, and unlike clang
targeting other aarch64 platforms) defaults to -fomit-frame-pointers
- lldb's code for looking up register values for `<same>` unwind rules
is recursive
- the test binary creates a very long chain of fp-less function frames
(it manages to fit about 22k frames before it blows its stack)

Together, these things have caused lldb to recreate the same deep
recursion when unwinding through this, and blow its own stack as well.
Since lldb frames are larger, about 4k frames like this was sufficient
to trigger the stack overflow.

This version of the patch works around this problem by increasing the
frame size of the test binary, thereby causing it to blow its stack
sooner. This doesn't fix the issue -- the same problem can occur with a
real binary -- but it's not very likely, as it requires an infinite
recursion in a simple (so it doesn't use the frame pointer) function
with a very small frame (so you can fit a lot of them on the stack).

A more principled fix would be to make lldb's lookup code non-recursive,
but I believe that's out of scope for this patch.

The original patch description follows:

A leaf function may not store the link register to stack, but we it can
still end up being a non-zero frame if it gets interrupted by a signal.
Currently, we were unable to unwind past this function because we could
not read the link register value.

To make this work, this patch:
- changes the function-entry unwind plan to include the `fp|lr = <same>`
rules. This in turn necessitated an adjustment in the generic
instruction emulation logic to ensure that `lr=[sp-X]` can override the
`<same>` rule.
- allows the `<same>` rule for pc and lr in all
`m_all_registers_available` frames (and not just frame zero).

The test verifies that we can unwind in a situation like this, and that
the backtrace matches the one we computed before getting a signal.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications