RegisterContextUnwind::SavedLocationForRegister is around 450 lines that first find an abstract register location (e.g. "CFA-8") for a register by looking in the UnwindPlans. Then it evaluates the abstract register location to create a concrete register location (e.g. "stored at address 0x...", "live in register at frame 0"). There are some complicated cases in the first half of the method to handle return address register architectures correctly, in particular. Looking at the two halves, they're both exactly 226 lines long and there's little involvement between them except for passing an abstract register location along. (there were some parts in the "abstract register location" code that would set the concrete register location, unnecessarily) It's also a complex enough method that there are some bits of code that aren't actually doing anything at this point. This patch adds a RegisterContextUnwind::GetAbstractRegisterLocation method, which does the first half, and has a clearly defined return values. The code to convert an AbstractRegisterLocation into a ConcreteRegisterLocation remains in SavedLocationForRegister. It's a bit of a tricky patch to visually inspect, despite it not changing functionality, the reorganizations and rewrites make the diff unreadable. Nearly all the real changes are in the "find the abstract register location" first half of the method. I think reading the new code in its new form is the easiest way to inspect this PR. With a defined interface between the two of what is expected, it's pretty easy to look at the code and reason about whether it is written correctly. (whereas before, that was very difficult, for me at least.) --------- Co-authored-by: Pavel Labath <pavel@labath.sk>
Basically, disable everything except the eh_frame unwind plan, as that's the only one which supports this right now. The other plans are working with now trying the interpret everything in between the function parts as a part of the function, which is more likely to produce wrong results than correct ones. I changed the interface for object file plans, to give the implementations a chance to implement this correctly, but I haven't actually converted PECallFrameInfo (its only implementation) to handle that. (from the looks of things, it should be relatively easy to do, if it becomes necessary) I'm also deleting UnwindPlan::GetFirstNonPrologueInsn, as it's not used, and it doesn't work for discontinuous functions.
AddressFunctionScope was always returning the first address range of the function (assuming it was the only one). This doesn't work for RegisterContextUnwind (it's only caller), when the function doesn't start at the lowest address because it throws off the 'how many bytes "into" a function I am' computation. This patch replaces the result with a call to (recently introduced) SymbolContext::GetFunctionOrSymbolAddress.
Re-landing this patch with small tweaks to address CI bot failures as it was run on many different configurations. I think the test may run on aarch64 Linux systems now. When a frameless function faults or is interrupted asynchronously, the UnwindPlan MAY have no register location rule for the return address register (lr on arm64); the value is simply live in the lr register when it was interrupted, and the frame below this on the stack -- e.g. sigtramp on a Unix system -- has the full register context, including that register. RegisterContextUnwind::SavedLocationForRegister, when asked to find the caller's pc value, will first see if there is a pc register location. If there isn't, on a Return Address Register architecture like arm/mips/riscv, we rewrite the register request from "pc" to "RA register", and search for a location. On frame 0 (the live frame) and an interrupted frame, the UnwindPlan may have no register location rule for the RA Reg, that is valid. A frameless function that never calls another may simply keep the return address in the live register the whole way. Our instruction emulation unwind plans explicitly add a rule (see Pavel's May 2024 change https://github.com/llvm/llvm-project/pull/91321 ), but an UnwindPlan sourced from debug_frame may not. I've got a case where this exactly happens - clang debug_frame for arm64 where there is no register location for the lr in a frameless function. There is a fault in the middle of this frameless function and we only get the lr value from the fault handler below this frame if lr has a register location of `IsSame`, in line with Pavel's 2024 change. Similar to how we see a request of the RA Reg from frame 0 after failing to find an unwind location for the pc register, the same style of special casing is needed when this is a function that was interrupted. Without this change, we can find the pc of the frame that was executing when it was interrupted, but we need $lr to find its caller, and we don't descend down to the trap handler to get that value, truncating the stack. rdar://145614545
This test is failing on the LLDB Incremental bot (arm64), which is running an older set of tools (Xcode 15.2) and OS (macOS 14.1) and the CFI directives must not be emitted correctly by either the tools or the OS. I will need to reproduce how this is compiling on that older setup and see what the issue is. Reverting for now so the bots are not blocked. This reverts commit e897cb139ee6ef5c145fed5394c4d96baa658e6b.
When a frameless function faults or is interrupted asynchronously, the UnwindPlan MAY have no register location rule for the return address register (lr on arm64); the value is simply live in the lr register when it was interrupted, and the frame below this on the stack -- e.g. sigtramp on a Unix system -- has the full register context, including that register. RegisterContextUnwind::SavedLocationForRegister, when asked to find the caller's pc value, will first see if there is a pc register location. If there isn't, on a Return Address Register architecture like arm/mips/riscv, we rewrite the register request from "pc" to "RA register", and search for a location. On frame 0 (the live frame) and an interrupted frame, the UnwindPlan may have no register location rule for the RA Reg, that is valid. A frameless function that never calls another may simply keep the return address in the live register the whole way. Our instruction emulation unwind plans explicitly add a rule (see Pavel's May 2024 change https://github.com/llvm/llvm-project/pull/91321 ), but an UnwindPlan sourced from debug_frame may not. I've got a case where this exactly happens - clang debug_frame for arm64 where there is no register location for the lr in a frameless function. There is a fault in the middle of this frameless function and we only get the lr value from the fault handler below this frame if lr has a register location of `IsSame`, in line with Pavel's 2024 change. Similar to how we see a request of the RA Reg from frame 0 after failing to find an unwind location for the pc register, the same style of special casing is needed when this is a function that was interrupted. Without this change, we can find the pc of the frame that was executing when it was interrupted, but we need $lr to find its caller, and we don't descend down to the trap handler to get that value, truncating the stack. rdar://145614545
This patch uses the previously build infrastructure to parse multiple FDE entries into a single unwind plan. There is one catch though: we parse only one FDE entry per unwind range. This is not fully correct because lldb coalesces adjecant address ranges, which means that something that originally looked like two separate address ranges (and two FDE entries) may get merged into one because if the linker decides to put the two ranges next to each other. In this case, we will ignore the second FDE entry. It would be more correct to try to parse another entry when the one we found turns out to be short, but I'm not doing this (yet), because: - this is how we've done things so far (although, monolithic functions are unlikely to have more than one FDE entry) - in cases where we don't have debug info or (full) symbol tables, we can end up with "symbols" which appear to span many megabytes (potentially, the whole module). If we tried to fill short FDE entries, we could end up parsing the entire eh_frame section in a single go. In a way, this would be more correct, but it would also probably be very slow. I haven't quite decided what to do about this case yet, though it's not particularly likely to happen in the "production" cases as typically the functions are split into two parts (hot/cold) instead of one part per basic block.
This reverts commit 094904303d50e0ab14bc5f2586a602f79af95953, reapplying d7afafdbc464e65c56a0a1d77bad426aa7538306 (#133247). The failure ought to be fixed by 0509932bb6a291ba11253f30c465ab3ad164ae08.