Remove unused freebsd elf32/elf64 header references

[omajid]

It doesn't make sense to require the freebsd-specific headers on non-FreeBSD platforms. In fact, on my testing, the headers aren't even used. And just break or do the wrong things when system libunwind is used.

[omajid]

cc @sec @Thefrank @joperator

[omajid]

cc @am11

[lambdageek]

It's not really a freebsd specific header - it's just the ELF spec.

But that said it doesn't seem like any of the ELF stuff is used by the dwarf writer. So it's ok to remove

[Thefrank]

It should be safe to remove.

FreeBSD builds currently use their own libunwind copy and I don't see anywhere else those ELF spec files would be used for FreeBSD.

[am11]

Yup, it's not related to freebsd, it was done as part of the consolidation work omajid@d2264b2, since HP libunwind has ditto headers under freebsd directory.

But that said it doesn't seem like any of the ELF stuff is used by the dwarf writer. So it's ok to remove.

Just make sure it's not breaking windows builds, since it's under HOST_WIN32.

[omajid]

Does this meet the bar for backporting to 9.0?

Without this change, .NET incorrectly uses the bundled libunwind (or fails to build if the bundled libunwind sources have been deleted as a preventive measure) even on x64 with a command like this:

./build.sh /p:NoPgoOptimize=true --portablebuild false /p:DotNetBuildFromSource=true /p:DotNetBuildSourceOnly=true /p:DotNetBuildTests=true --cmakeargs -DCLR_CMAKE_USE_SYSTEM_BROTLI=true --cmakeargs -DCLR_CMAKE_USE_SYSTEM_LIBUNWIND=true --cmakeargs -DCLR_CMAKE_USE_SYSTEM_RAPIDJSON=true --cmakeargs -DCLR_CMAKE_USE_SYSTEM_ZLIB=true --runtimeconfiguration Release --librariesConfiguration Debug /p:PrimaryRuntimeFlavor=Mono --warnAsError false --subset clr+mono+libs+host+packs+libs.tests

[am11]

Without this change, .NET incorrectly uses the bundled libunwind

What is the error message and on which platform? This is used by mono-windows as a header only include. It doesn't compile the libunwind.

[omajid]

What is the error message and on which platform?

In our CI setup, when using system libraries, we rm the bundled libunwind implementation. The leg that builds on x64 with mono fails with:

  -- Configuring done (29.3s)
  CMake Error at mono/utils/CMakeLists.txt:257 (add_library):
    Cannot find source file:
  
      /home/tester/runtime/src/native/external/libunwind/include/remote/freebsd-elf_common.h
  
  
  -- Generating done (0.1s)
  CMake Warning:
    Manually-specified variables were not used by the project:
  
      CLR_CMAKE_USE_SYSTEM_LIBUNWIND
      CLR_CMAKE_USE_SYSTEM_RAPIDJSON
  

[am11]

we rm the bundled libunwind implementation.

To avoid accidental building? I see this rationale, but isn't it a bit too eager; considering llvm-libunwind in the same src/native/external directory is kept (because we can't use the stock version of that lib as no one has upstreamed the patches); why this treatment is exclusive for HP libunwind? 😅

You could keep the remote directory and delete the rest:

- rm src/native/external/libunwind
+ find src/native/external/libunwind -mindepth 1 ! -regex '^src/native/external/libunwind/include/remote\(/.*\)?' -delete

[omajid]

Okay, that's fair. Thanks!