[lldb][swift] Use frame formation as a guide for async unwinding #10637
Conversation
|
@swift-ci test |
| /// function, this offset is UINT_MAX. | ||
| /// 2. The CFA offset at which FP is stored. | ||
| static llvm::Expected<FrameSetupInfo> | ||
| GetFrameSetupInfo(UnwindPlan &unwind_plan, RegisterContext ®ctx) { |
There was a problem hiding this comment.
@jasonmolenda this is the most important function of this patch.
|
None of those are failing locally... investigating. CI builds with debug info, but it should not matter here... |
|
Ah I made the mistake of assuming the x86 plan would track FP always, like the arm plans do. @jasonmolenda had previously mentioned we have this inconsistency where "same" can be expressed both as a rule "same" and as the absence of a rule. |
felipepiovezan
force-pushed
the
felipe/frame_formation_based_unwinding
branch
from
6355d5a to
781dccd
Compare
|
@swift-ci test |
|
@swift-ci test windows platform |
| /// Detect the point in the function where the prologue created a frame, | ||
| /// returning: | ||
| /// 1. The offset of the first instruction after that point. For a frameless | ||
| /// function, this offset is UINT_MAX. |
There was a problem hiding this comment.
(or, as we typically do for addr_t, LLDB_INVALID_ADDRESS, although we all know addr_t is just a UInt64)
There was a problem hiding this comment.
I was trying to avoid LLDB_INVALID_ADDRESS because I wanted to make it clear that one can compare PC against this value with <. I'll spell it to make this clear.
|
|
||
| // This is a frameless function, use an infinite offset to represent this. | ||
| if (it == fp_locs.end()) | ||
| return FrameSetupInfo{std::numeric_limits<addr_t>::max(), 0}; |
There was a problem hiding this comment.
Might be better to use UINT64_MAX here to match the description above.
There was a problem hiding this comment.
This makes me a bit anxious, as this type could very well be int64_t (even though it isn't). So I wanted to be very explicit that this is a large positive number.
Let me tweak the comment.
| // 2. save fp @ CFA-16 << `it` points to this row. | ||
| // 3. save async_reg @ CFA-24 << subsequent row. | ||
| // Use subsequent row, if available. | ||
| int row_idx = fp_locs.end() - it; |
There was a problem hiding this comment.
I'm not sure if you're showing the instruction sequence or the rows here. A typical AArch64 prologue can be
sub sp, sp, #0x20
stp fp, lr, [sp, #0x10]
add fp, sp, #0x10
If this is arm64e (ARMv8.3 ptrauth) codegen, there will be a pacibsp instruction to add auth bits to lr before it is spilled to stack.
Then from an unwind rule perspective we'll see
0th row: unwind state on function entry (pc=lr)
1st row: adjust sp (CFA is in terms of sp)
2nd row: store caller's fp & lr (CFA is in terms of sp)
3rd row: copy stack pointer + offset into fp reg (CFA is in terms of fp)
So we'll identify row 2 (the third row) as the point where fp has been saved to stack at CFA+offset, in nearly all prologues.
I'm mostly not clear what the numbering in this comment is representing - instructions or unwind rows.
There was a problem hiding this comment.
I'm mostly not clear what the numbering in this comment is representing - instructions or unwind rows.
Neither! It was just meant to be: "this is roughly the order in which things happen". I'll update the comment to make this clear and remove numbers altogether
This patch changes how the swift language runtime obtains the async context of the currently executing function. The old strategy consists of querying unwind plans for what they believe the location of the async register is. This proved problematic in cases where the register is not saved directly, e.g. in arm64e, where the register is signed and moved to a scratch register prior to being saved. The new strategy relies on ABI guarantees: the async context is _always_ saved at the stack slot immediately beneath where FP is saved. As long as a frame has been formed, we can always access the async context by reading memory @ [CFA-24] (FP is saved in [CFA-16]). Before the frame is formed, the async register can be accessed directly. In other words, the main problem this patch has to solve is detecting the point at which a frame has been fully formed. This is accomplished by scanning the first few Rows of the assembly unwind plan, until a Row is found where FP's location is "AtCFAPlusOffset". The Row immediately after that is used. This is reliable because async prologues follow this pattern in all tested architectures (x86-64, arm64, arm64e): // 0. adjust sp // 1. save lr @ CFA-8 // 2. save fp @ CFA-16 // 3. save async_reg @ CFA-24 << "row immediately after" For frameless functions, we can always use the async register directly. While this patch adds no tests, all of the existing stepping tests and tests inspecting variables exercise the new behavior.
felipepiovezan
force-pushed
the
felipe/frame_formation_based_unwinding
branch
from
781dccd to
d1ac271
Compare
|
@swift-ci test |
This patch changes how the swift language runtime obtains the async context of the currently executing function.
The old strategy consists of querying unwind plans for what they believe the location of the async register is. This proved problematic in cases where the register is not saved directly, e.g. in arm64e, where the register is signed and moved to a scratch register prior to being saved.
The new strategy relies on ABI guarantees: the async context is always saved at the stack slot immediately beneath where FP is saved. As long as a frame has been formed, we can always access the async context by reading memory @ [CFA-24] (FP is saved in [CFA-16]). Before the frame is formed, the async register can be accessed directly.
In other words, the main problem this patch has to solve is detecting the point at which a frame has been fully formed. This is accomplished by scanning the first few Rows of the assembly unwind plan, until a Row is found where FP's location is "AtCFAPlusOffset". The Row immediately after that is used. This is reliable because async prologues follow this pattern in all tested architectures (x86-64, arm64, arm64e):
// 0. adjust sp
// 1. save lr @ CFA-8
// 2. save fp @ CFA-16
// 3. save async_reg @ CFA-24 << "row immediately after"
For frameless functions, we can always use the async register directly.
While this patch adds no tests, all of the existing stepping tests and tests inspecting variables exercise the new behavior.