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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
