[Lldb-commits] [lldb] Reapply "[lldb/aarch64] Fix unwinding when signal interrupts a leaf f… (PR #92503)

[Jason Molenda via lldb-commits]

jasonmolenda wrote:

> The way I see it, this check (at least the part about the RA register(*)) is heuristic that's impossible to get always right. Like, I could construct a test case using functions with non-standard ABIs where a non-leaf function legitimately has a `lr=<same>` rule. Such code would execute correctly but lldb would refuse to unwind it due to the `lr=<same>` restriction.

This would be an interesting idea.  I don't think there's any unwind format which allows you to specify that a different register holds the return address, and lr is IsSame.  You could say that lr=x9 to say that the return address is in x9, but you can't express that the return address is stored in a non-lr register.  You could add an unwind rule for pc=x9 to say that the return address is in x9, and depend on the unwinder to not look for lr, but to try retrieving pc first.

> 
> All of this is to say that I don't think there is a way to change this piece of code to be correct all the time -- we'd just be trading one set of edge cases for the other. I think that the most correct solution would be to remove this check altogether. I'm not sure why it exists, but I expect it has something to do with preventing looping stacks. 

The original goal was that if we're on frame 1, we don't want to surface a register value from frame 0 and use it in frame 1 unless it's a callee-spilled register.   e.g. x0 on frame 1 may have been overwritten while frame 0 was executing, there is no unwind rule for x0 and the unwinder can't show frame 0's x0 value in frame 1.   But if we're above a sigtramp etc frame which has the entire register context from when a function was interrupted, we can retrieve all the registers and want to show them.

> (*) I'm only talking about the `lr` rule everywhere. I _think_ that a `pc=<same>` rule would always be an error (even in signal handlers), so we should be able to keep that here. OTOH, if our loop detection code is robust enough, then there should be no harm in letting this through either...


Yeah I think there's improvements that can be made here for sure.


https://github.com/llvm/llvm-project/pull/92503