coreclr build fails when specifying cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE

[dseefeld]

When trying to build coreclr using the system version of libunwind, the build fails with the following error:

$ ./build.sh cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE
...
../../dlls/mscordac/libmscordaccore.so: undefined reference to `_OOP_find_proc_info'
clang-9: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [src/debug/createdump/createdump] Error 1
gmake[1]: *** [src/debug/createdump/CMakeFiles/createdump.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[100%] Built target mscordbi
gmake: *** [all] Error 2
Failed to build CoreCLR component.

[hoyosjs]

What system/OS is this?

[hoyosjs]

@mikem8361 looks like this comes from our work in ARM unwinding (b61cc2f). Looks like _OOP_find_proc_info was added directly to libunwind. However this function only gets build then:

runtime/src/coreclr/src/pal/src/CMakeLists.txt

Line 16 in 696e72b

add_subdirectory(libunwind)

The easiest solution would be to hoist such logic into another statically linkable asset, but if memory serves he right we use types that are not available in the public libunwind surface area.

@dseefeld is this for sourcebuild? What's the impact if so? Or is this more around serviceability or the ability to build like that?

[dseefeld]

@hoyosjs Yes. This is for sourcebuild. The impact is that RedHat has requested that we use the local system's libunwind for portable builds. See dotnet/source-build#391 The OS that I'm using to build this is CentOS.

[sdmaclea]

libunwind/libunwind#187 is starting the process of adding _OOP_find_proc_info to libunwind, but it is unlikely to make it into system version of libunwind for a while. It would need to wait at least to the 1.6 release. (1.5 isn't released yet).

Since this is only needed for the DAC unwind, the solution maybe to either:

• Disable the the DAC Out of Process unwind feature.
• Use the local libunwind source for DAC only.

[mikem8361]

> • Disable the the DAC Out of Process unwind feature.

This breaks a lot of stack traces that have HelpMethodFrames (fairly common), but it is limited to dotnet-dump/CLRMD on coredumps. Live managed debugging and live SOS debugging under lldb will work fine.

> • Use the local libunwind source for DAC only.

This still breaks the source build because the DAC is still built along with the rest of the runtime. But maybe our source build customers would like it slide (RHEL).

[sdmaclea]

I guess the third option would be to revert part of #26082 (to keep our custom oop code) when CLR_CMAKE_USE_SYSTEM_LIBUNWIND=TRUE until libunwind/libunwind#187 is released and available to RHEL.