-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Remove usage of HP libunwind on Apple platforms #110023
base: main
Are you sure you want to change the base?
Changes from 1 commit
a3e1a72
cc5afa3
8d38616
9c3fb30
9aa1e0a
67d8271
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -34,9 +34,13 @@ extern "C" { | |||
|
||||
#include <inttypes.h> | ||||
#include <stddef.h> | ||||
#include <ucontext.h> | ||||
#include <stdalign.h> | ||||
#include <stdint.h> | ||||
#ifdef __APPLE__ | ||||
#include <sys/ucontext.h> | ||||
#else | ||||
#include <ucontext.h> | ||||
#endif | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please upstream this patch (https://github.com/libunwind/libunwind) and add a line next to
The next update (v1.9) will automatically pick it up from upstream, eliminating the need for manual verification on our end. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is just CI test at this point. This should not even be used on Apple platforms but I think DAC references it for one reason or another. I'd rather resolve that and drop the change in libunwind. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yup, windows and macOS only use HP libunwind for remote unwinding feature. It's a bit unfortunately that llvm-libunwind doesn't provide that and HP libunwind doesn't fully support macOS. Converging to one lib was attempted a few times but there isn't a substantial progress on that front. :( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I checked the code and there's actually three unwinding libraries...
LLVM libunwind actually does provide remote unwinding but only in the C++ API. That's essentially the API used by UnwindHelpers.cpp in NativeAOT. There's a way to pass custom It would probably be possible remove the use of HP libunwind on Apple platforms with relatively minor changes. It's only used for few structs that are not exposed externally and as a fallback that should never be hit (since both compact unwinding and DWARF unwinding is implemented in remote-unwind.cpp). Am I missing something here? Maybe some CrossDAC scenarios? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Sounds good. I think we should go ahead with the switch. Both mac and windows have minimal remote unwind helpers in HP-libunwind which were upstreamed from dotnet/runtime: https://github.com/libunwind/libunwind/tree/master/src/remote We have the option to build coreclr with llvm-libunwind on linux as well, which has been supported since 2016: 5a2478f (not sure if it's been tested recently though). Also, The majority of HP-libunwind usage in coreclr is due to
The result of: AFAICT, the llvm-libunwind project started back in 2013 when Apple contributed their unwinder to LLVM. While the system libunwind on macOS may have diverged somewhat, their C API seems to be the same as llvm-libunwind (which itself uses consistent naming as the original HP-libunwind), with the exception of for three functions we care for: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The diff for removing the HP libunwind fallback on Apple platforms seems to be quite small. Let's see if I broke anything on CI. Honestly, not very sure on how to test it. I am not aware of any createdump tests. |
||||
|
||||
#ifndef UNW_EMPTY_STRUCT | ||||
# define UNW_EMPTY_STRUCT uint8_t unused; | ||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is basically reverting 796cbee. ucontext.h is POSIX while sys/ucontext.h is platform detail. Please put it under
TARGET_OSX
if it is only needed on mac.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I suppose you are technically correct. We actually have some unguarded usages of
sys/ucontext.h
and few ones that are guarded withHAVE_SYS_UCONTEXT_H
. That convinced me that all supported platforms actually havesys/ucontext.h
.This originally started off as an attempt to avoid defining
_XOPEN_SOURCE
. Weirdly enough the commit you referenced should have made it defined everywhere, yet I had build failures related to it, and it's still redefined in NativeAOT and Mono CMakeFiles.Context: #109928 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, the current version of the code explains the bit:
I wonder why the mobile platforms were excluded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#110092. Let's check that first. If it gets accepted then I can revert back to
<ucontext.h>
.