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.

[omajid]

cc @tmds

[mikem8361]

Adding @jashook

[tmds]

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.

So this option is: allow to use the system libunwind, and provide _OOP_find_proc_info as part of the runtime repo?

This seems like the most interesting option to me.

[mikem8361]

The problem is the functions that _OOP_find_proc_info uses are internal to libunwind.

[tmds]

Until @sdmaclea 's libunwind PR gets merged and becomes available, the least work is to use the packed libunwind.
We can look at backporting the PR for distros we care about.

We should keep this issue open to get CLR_CMAKE_USE_SYSTEM_LIBUNWIND=true back in a working state.

@omajid wdyt?

[tmds]

@sdmaclea are you still actively pursuing libunwind/libunwind#187?

@omajid are you ok with using the packed libunwind until the feature is available as part of system libunwind?
We can consider backporting it once the feature is merged upstream.

[sdmaclea]

I have been working on other issues. I can probably look at libunwind/libunwind#187 later this week.

[sdmaclea]

#39213 restored some of the code which was removed in #26082. It makes it simpler to fix this issue more directly. @mikem8361 has been considering an approach like this...

[mikem8361]

Now that PR #39213 is in I was planning to add the rest of the necessary code and build stuff in the next month. It missed today's preview8 snap but it be done in the next week or two.

[mikem8361]

I have this coded up and I'm testing.

[omajid]

@omajid are you ok with using the packed libunwind until the feature is available as part of system libunwind? We can consider backporting it once the feature is merged upstream.

Yes, we can use the bundled libunwind until the features are available upstream.