-
Notifications
You must be signed in to change notification settings - Fork 38
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
backport arm64 fixes for msys2-3_3_6-release #235
Merged
lazka
merged 2 commits into
msys2:msys2-3_3_6-release
from
jeremyd2019:msys2-3_3_6-test-arm64
Nov 13, 2024
Merged
backport arm64 fixes for msys2-3_3_6-release #235
lazka
merged 2 commits into
msys2:msys2-3_3_6-release
from
jeremyd2019:msys2-3_3_6-test-arm64
Nov 13, 2024
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://cygwin.com/pipermail/cygwin/2024-February/255397.html reports a crash on ARM64 probably related to checking x86_64 code on the x86_64 emulator on AArch64. At least for testing, pull the code checking the host HW up to be called before trying to evaluate assembler code. Signed-off-by: Corinna Vinschen <[email protected]>
This addresses an extremely difficult to debug deadlock when running under emulation on ARM64. A relatively easy way to trigger this bug is to call `fork()`, then within the child process immediately call another `fork()` and then `exit()` the intermediate process. It would seem that there is a "code emulation" lock on the wait thread at this stage, and if the thread is terminated too early, that lock still exists albeit without a thread, and nothing moves forward. It seems that a `SuspendThread()` combined with a `GetThreadContext()` (to force the thread to _actually_ be suspended, for more details see https://devblogs.microsoft.com/oldnewthing/20150205-00/?p=44743) makes sure the thread is "booted" from emulation before it is suspended. Hopefully this means it won't be holding any locks or otherwise leave emulation in a bad state when the thread is terminated. Also, attempt to use `CancelSynchonousIo()` (as seen in `flock.cc`) to avoid the need for `TerminateThread()` altogether. This doesn't always work, however, so was not a complete fix for the deadlock issue. Addresses: https://cygwin.com/pipermail/cygwin-developers/2024-May/012694.html Signed-off-by: Jeremy Drake <[email protected]>
I don't use msys2-runtime-3.4, and don't see any use case for it on arm64, so I haven't tried to backport anything to it. |
lazka
added a commit
to msys2/MSYS2-packages
that referenced
this pull request
Nov 13, 2024
Does this also need #236? |
yes. I was waiting for confirmation that it fixed the issue. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since I already did this for testing on Windows 10 ARM64, I thought I'd open a PR for these too. This is effectively #233 and #234