New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NativeAOT/linux-arm64] AF: codeManager->IsUnwindable(pvAddress) || runtime->IsConservativeStackReportingEnabled() #101896
Comments
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas |
@VSadov Could you please take a look? We seem to be hitting it for calls right before epilogs: Example:
|
The ip seems to be in epilog. There should not be interruptible points in epilog. That is what could trigger the assert. |
The problem is not with the call being right before an epilog, but with detecting epilogs on linux-ARM64 in general. The #101647 started using LR as a general purpose register when doing indirect calls and that broke our logic that detects whether a thread is in an epilog on linux-arm64 Using LR as a GPR is not illegal, just something that we did not do before, so once we see LR (or FP) loaded with some value, the epilog detection logic assume that we are in an epilog. Long-term (and assuming that some platforms will never learn how to unwind in epilogs), I think we should encode the epilog ranges, in GC info, I suppose. It will not be trivial as there could be more than one epilog in a method, so encoding them all and then searching through them could be a bit tricky. For now we can have a simpler fix - we do not have to use LR for indirect calls, In fact |
IIRC, we have been using LR as a general-purpose register for a long time, it just did not happen very often in practice. |
We would have seen this assert once in a while then. I think one of the reasons why #101647 could unconditionally use LR for indirect calls register is that LR is not generally used as GPR. (that is not a case on arm32 though, where registers are in a short supply and LR is used as a scratch) We need to confirm this until we have a better solution (i.e. #101932) |
It looks like LSRA excludes LR from availableIntRegs runtime/src/coreclr/jit/lsra.cpp Lines 790 to 792 in 91b32f6
Not sure if that is sufficient to prevent its use as a GPR. Looks like that is the intent there. |
@jakobbotsch @AndyAyersMS - Is the exclusion of LR from (just want to make sure the current assumption is safe) |
I picked
Yes, that should be sufficient (I verified this as well). |
I'm not sure why exactly |
ABI seems to permit using LR as a scratch, but I would not be surprised if using LR as GPR could break something. Some asm stub could be forgetting to treat is as a scratch or some tooling issue. It could be just a defensive change while dealing with other bugs. I will add a comment about the dependency that we know about. We can consider allowing using LR as scratch once #101932 is addressed. |
It would be a bug that we would want to fix. (I have seen it used as a scratch in C/C++ compiled code too.) |
Native AOT outer loop tests are hitting this assert very frequently:
Examples:
https://github.com/dotnet/runtime/pull/85694/checks?check_run_id=24608826010
https://github.com/dotnet/runtime/pull/101858/checks?check_run_id=24608136220
https://github.com/dotnet/runtime/pull/101767/checks?check_run_id=24511487322
The text was updated successfully, but these errors were encountered: