Update llvm-libunwind to v18

[am11]

First commit: deleted llvm-libunwind/ and downloaded fresh copy from v18.1.5 tree.
Second commit: apply all our local patches.
Third commit: updated the version file (noting second commit).

These local patches are growing, making it a bit tricky to update.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

[am11]

It was deleted in llvm/llvm-project@1ae57fe.

[jkoritzinsky]

If these patches are getting difficult to update, are there subsets we can upstream to make it easier/slim down the diff?

[am11]

If these patches are getting difficult to update, are there subsets we can upstream to make it easier/slim down the diff?

That would be nice; #72655. 😅
I think it's best if original authors send their respective patches to avoid losing context and authorship, otherwise we can open PRs on their behalf (git commit --amend --author="name <email>" --no-edit).

[am11]

I think this change could use running additional legs for AOT testing.

[janvorli]

Just a note to fix it in a separate PR.
This change is actually problematic. Loading SP early may cause corruption of the source context in case it is located on stack and an async signal fires. See #101709. We will need to do something similar to how it was fixed in the linked issue if we need to restore x16 too.

[am11]

@janvorli, thanks. In case you missed it, it's the first commit which put v18 code, then second commit applied our patches which undid this change. So in the current state of the PR, ti's not available. Would be nice to sync it with upstream at some point because they touched nearby code in recent updates.

[janvorli]

I understand, I meant that our state was problematic and that the V18 way is correct, except that it trashes x16. But I have missed the comment above that says that trashing x16 is ok. So maybe we should take the new code here?

[am11]

Sure, we can try it in a follow-up PR. Seems like it was like that from the beginning of the port: https://github.com/dotnet/corert/blame/c6af4cfc8b625851b91823d9be746c4f7abdc667/src/Native/libunwind/src/UnwindRegistersRestore.S#L585 and we diverged from upstream in llvm 9 timeframe llvm/llvm-project@d5323f6 (a change we never picked).

[janvorli]

Right, I guess we have just missed that change and skipping it was not intentional.

[jkotas]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[am11]

Timeouts look unrelated. Perhaps one more outerloop run will help validating the update? 👀

[janvorli]

I can see that Threading NativeAOT tests are failing, which was fixed last week. Let me close and reopen the PR to pick the fix to this issue and rerun the outerloop.

[janvorli]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[am11]

In the history tabs of those failing tests in AzDo, they seem to have intermittently failed before on main as well, so I'm not completely sure if they are related to this version bump.

[am11]

linux-arm failure is being fixed by #102760 and System.IO tests on linux-x64 are also failing on main. e..g. https://dev.azure.com/dnceng-public/public/_build/results?buildId=689281&view=logs&j=20e6f673-0b0c-5c85-377c-5d941d4c8ee3&t=5801e1cc-59c5-5e47-8484-142b970afd58

[SKIP] System.IO.Tests.TextWriterTests.CreateBroadcasting_AllMethodsOverridden
./RunTests.sh: line 179:    21 Killed                  ./System.IO.Tests -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing -xml testResults.xml $RSP_FILE
/root/helix/work/workitem/e
----- end Tue May 28 10:50:09 UTC 2024 ----- exit code 137 ----------------------------------------------------------
exit code 137 means SIGKILL Killed either due to out of memory/resources (see /var/log/messages) or by explicit kill.
ulimit -c value: unlimited