Linker warnings on OSX

[MichalStrehovsky]

We get 3 kinds of warnings:

ld : error : could not create compact unwind for _System_Net_Http_System_Net_Http_Headers_QPackStaticTable___cctor: stack subq instruction is too different from dwarf stack size [/Users/runner/work/1/s/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]
ld : error : can't parse dwarf compilation unit info in /Users/runner/work/1/s/artifacts/obj/System.Runtime.Tests/net6.0-Unix-Release/native/System.Runtime.Tests.o [/Users/runner/work/1/s/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]
ld : error : linker symbol '$ld$hide$os10.4$__Unwind_Backtrace' hides a non-existent symbol '__Unwind_Backtrace' [/Users/runner/work/1/s/src/libraries/System.Runtime/tests/System.Runtime.Tests.csproj]

1. My theory was that disabling compact unwind generation in the linker would fix the first. It broke exception handling. There's an option to keep dwarf unwind. Maybe we need to set that.
2. My theory based on seeing lld64 source code was that we're generating DWARF that is too new (Apple is typically a decade in the past when it comes to computer standards and seem to only support DWARF 3)
3. __Unwind_Backtrace should have been defined by libSystem that we drag in because of the dependency on libm. But maybe not?

Anyways, I burned too much time on this and I personally do not care about Apple. This is up for grabs.

[kant2002]

Where this is happens ?

[MichalStrehovsky]

Where this is happens ?

On macOS. I think even a hello world will hit a bunch of these.

[miried]

I can confirm these warnings on macos, triggered by any F# app that I compile. Even a standard "hello world". The same code will compile fine on linux.

[filipnavara]

can't parse dwarf compilation unit info

There's a bug in the LLVM MC code for the implicit DWARF generation. The debug information should use section relative offsets with no relocations. The Mach-O backend ensures that in the relocation emitting code by looking up MCFragment and then its atom to find the section defining symbol which is then used as the relocation target. However, due to the way the Finish call sequence is structured in regards to the DWARF info generation it happens that the step where atoms are assigned to fragments is run before the DWARF generation. The relocation code then fails to lookup the section defining symbols and emits absolute addresses instead of relative ones.

Long story short, dotnet/llvm-project#269 switched objwriter to fully custom DWARF generation that doesn't suffer from the same problem. It no longer calls OutContext->setGenDwarfForAssembly(true); so the implicit DWARF generation doesn't take place and offsets in the object file are now correct.

[filipnavara]

ld : error : could not create compact unwind for _System_Net_Http_System_Net_Http_Headers_QPackStaticTable___cctor: stack subq instruction is too different from dwarf stack size

This is likely solved now by switch to DWARF CFI across the board. The ld64 and LLVM algorithm for generating compact unwinding codes cannot convert prologs that do __chkstk pattern.

[filipnavara]

Should we close this now? macOS support works as of .NET 8 RTM.