Remove usage of HP libunwind on Apple platforms

[filipnavara]

• Replace usage of <ucontext.h> with <sys/ucontext.h>. Apple's implementation of <ucontext.h> only works with the _XOPEN_SOURCE definition and contains some deprecated functions that .NET never really references. This simplifies the build a bit.
• Remove fallback to HP libunwind in remote-unwind.cpp. There's already an implementation copied from LLVM's libunwind that handles both compact unwinding and DWARF.

[am11]

Please upstream this patch (https://github.com/libunwind/libunwind) and add a line next to

runtime/src/native/external/libunwind-version.txt

Line 13 in a3e1a72

Apply https://github.com/libunwind/libunwind/pull/741

The next update (v1.9) will automatically pick it up from upstream, eliminating the need for manual verification on our end.

[filipnavara]

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.

[am11]

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. :(

[filipnavara]

I checked the code and there's actually three unwinding libraries...

• HP libunwind
• LLVM libunwind
• The copied LLVM libunwind logic in remote-uniwind.cpp under __APPLE__ guard

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 AddressSpace implementation and initial register values. However, using that would be substantial rewrite and I am not sure if we have test coverage for that.

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?

[am11]

It would probably be possible to remove the use of HP libunwind on Apple platforms with relatively minor changes.

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, unw_get_save_loc API (which was the main reason of using HP-libunwind #4193 (comment)) was implemented in our in-tree copy of llvm-libunwind since dotnet/corert@c6571c6, though we haven’t upstreamed those patches yet. There’s an open issue for this: #72655, which is a minor problem; it’s simply something we continue to carry forward during llvm-libunwind version bumps.

The majority of HP-libunwind usage in coreclr is due to HELPER_METHOD_FRAME (HMF) and FCThrow: dotnet/corert#3784. Work is actively ongoing to remove these, and folks have made good progress: #95695. We are down to ~80 instances of HMF from 400+, and FCThrow is down to ~75. Once the HMF removal is completed, we can revisit the remaining uses of HP-libunwind, particularly for remote unwinding.

CrossDAC

The result of:
git grep -E 'libunwind|unw_' -- 'src/coreclr' ':!src/coreclr/pal' ':!src/coreclr/nativeaot'
command suggests that we don’t have direct usages of libunwind outside of the CoreCLR-PAL (I maybe missing something), which means we might be able to switch everything over to llvm-libunwind if we switch PAL to llvm-libunwind. Once HMF is removed, PAL implementation can be reduced to bare minimum without having to work out two libunwind flavors.

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: unw_get_save_loc (which our llvm-libunwind copy includes), unw_get_accessors (which we don’t directly use but cmake introspection is in pal/src/configure.cmake for some reason..), and unw_get_proc_info_in_range (for which we have a fallback implementation that matches the one originally ported by us to HP-libunwind upstream, and it works with llvm-libunwind as well).

[filipnavara]

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.

[filipnavara]

Keeping as draft until we come up with a test for this. /cc @dotnet/dotnet-diag

[am11]

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.

[filipnavara]

Hmm, I suppose you are technically correct. We actually have some unguarded usages of sys/ucontext.h and few ones that are guarded with HAVE_SYS_UCONTEXT_H. That convinced me that all supported platforms actually have sys/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)

[filipnavara]

Ah, the current version of the code explains the bit:

elseif(CLR_CMAKE_HOST_OSX AND NOT CLR_CMAKE_HOST_MACCATALYST AND NOT CLR_CMAKE_HOST_IOS AND NOT CLR_CMAKE_HOST_TVOS)
  add_definitions(-D_XOPEN_SOURCE)

I wonder why the mobile platforms were excluded.

[filipnavara]

#110092. Let's check that first. If it gets accepted then I can revert back to <ucontext.h>.