Fix llvm-libunwind context sizes

[am11]

As discussed here: #72655 (comment)

[dotnet-policy-service]

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

[am11]

@janvorli this is ready.

---

In our patches, we are doing stuff like

- template <typename A>
- int CompactUnwinder_arm64<A>::stepWithCompactEncoding(
+ template <typename A, typename R>
+ int CompactUnwinder_arm64<A, R>::stepWithCompactEncoding(

even though these are arch-specific, we pass our own R=Registers_REGDISPLAY to satisfy the static_asserts which check for A<=R match and fail upstream.

Not sure if it is possible at all to upstream the patches in a manner that distro provided llvm-libunwind can be used without needing to rebuild a different flavor for .NET, if we can determine it's not, we should just remove

runtime/eng/DotNetBuild.props

Line 118 in 62f3b4d

<!-- TODO: llvm-libunwind -->

cc @tmds

[janvorli]

This change was added relatively recently in in cb6fb60. I wonder if we can do it differently to minimize the changes upstream.

[am11]

It is probably possible to make C API contracts (in libunwind.h) and not directly modify the (internal) C++ APIs.

[janvorli]

Not sure if it is possible at all to upstream the patches in a manner that distro provided llvm-libunwind can be used without needing to rebuild a different flavor for .NET

I am not sure either. Some things might be solved by not using REGDISPLAY inside of the libunwind at the cost of some copying of the context, but there were other changes made where we access internals of the libunwind for performance reasons, like dotnet/corert#5076. That is not something we could without using the full sources.

[am11]

I think it is a reasonable explanation. The portion of llvm-libunwind used in NativeAOT is an internal detail. In coreclr PAL, HP libunwind is strictly used via the public API, so the choice of using system libunwind in source-build is feasible.

BTW, llvm-libunwind lists 200 dwarf codes

runtime/src/native/external/llvm-libunwind/src/dwarf2.h

Line 20 in 4b2fe3c

enum {

(despite the name, it's for all DWARF versions) out of which they handle 54 unique cases (rest are grouped):

runtime/src/native/external/llvm-libunwind/src/DwarfInstructions.hpp

Line 459 in 4b2fe3c

switch (opcode) {

ilc objwriter has writer implementation in the directory where these ~530 codes live (could be reduced to the same number llvm-libunwind supports)

runtime/src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/ObjectWriter/Dwarf/DwarfNative.cs

Line 6 in 4b2fe3c

internal static class DwarfNative

maybe with some effort, we can add DwarfReader as well to coin our own run-time unwinder to get rid of llvm-libunwind dependency; given we are half way there dealing with binary formats without any dependency.

[janvorli]

@am11 I am sorry, this got out of my radar. I have just closed / reopened the PR to recheck stuff.

[agocke]

@janvorli anything else?

[janvorli]

@agocke I'm fine with it. The build analysis seems to be somehow confused, it shows errors that the list above doesn't show.

[agocke]

/ba-g failures from BA are stale