Remove usage of HP libunwind on Apple platforms

[filipnavara]

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.

[filipnavara]

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

[mikem8361]

Removing this code breaks a fallback path if HAVE_GET_PROC_INFO_IN_RANGE is not set and not HOST_UNIX. I'm not sure exactly what platforms still will use that path (see line 2398).

[am11]

HAVE_GET_PROC_INFO_IN_RANGE is not defined on Unix when libunwind lacks support for unw_get_proc_info_in_range. This function is only available in HP libunwind version 1.6 and later. To ensure compatibility, we need to handle this for LLVM libunwind and HP libunwind versions earlier than 1.6.

[filipnavara]

That's a fundamental misunderstanding of what this PR does (or I am missing something).

This code is Apple specific. It was called explicitly on Apple platforms already without any libunwind involvement (aside from operating on the same structures). I completely removed the code path that goes to (HP) libunwind on Apple platforms because there are only two unwinding encodings (compact unwinding and DWARF; with the DWARF always using compact unwinding as index because the linker enforces that) and both are already handled by the special Apple code path.

[mikem8361]

ExtractProcInfoFromFde is not Apple specific. Yes, most of the calls are in Apple specific except here:

runtime/src/coreclr/pal/src/exception/remote-unwind.cpp

Line 2398 in 342936c

if (!ExtractProcInfoFromFde(info, &fdeAddr, pip, need_unwind_info)) {

[filipnavara]

Hmm. I think that code path never takes place with the HP libunwind fork that we ship. It may be relevant for platforms that use system libunwind (FreeBSD or Haiku). I can add that code path back...

[mikem8361]

Yes, add it back to make sure ever platform is covered.

[janvorli]

There's already an implementation copied from LLVM's libunwind that handles both compact unwinding and DWARF.

Are you referring to the copy of the whole LLVM's libunwind in src/native/external/llvm-libunwind? If that's the case, that implementation is not used on CoreCLR, it is only for NativeAOT.

[filipnavara]

Are you referring to the copy of the whole LLVM's libunwind in src/native/external/llvm-libunwind?

No. I am referring specifically to the code in remote-unwind.cpp that's guarded by __APPLE__ definition:

runtime/src/coreclr/pal/src/exception/remote-unwind.cpp

Line 1307 in 7ccf491

//===-- CompactUnwindInfo.cpp ---------------------------------------------===//

HP libunwind doesn't know how to handle Apple compact unwinding. So the LLVM code was copied there. Whoever copied it also included the DWARF code paths too, which renders the HP libunwind fallback moot on Apple platforms since both cases are already covered by the Apple specific code.

[filipnavara]

Closing for now. I realized this is flawed in concept for non-compact unwinding where HP libunwind was still used to interpret the DWARF opcodes.

I may do another take with trying to use llvm-libunwind C++ API (as used by NativeAOT).