Skip to content

Conversation

@lambdageek
Copy link
Member

The flag tells the linker that there are no functions with overlapping code and thus the code sections can be divided into subsections based on the symbols. This is similar in effect to how -ffunction-sections behaves on ELF.

Notably, this enables optimization such as dead code stripping and identical code folding, if requested through linker switches.

Old ld64 linker tends to run into deep stack loop without this switch if -dead_strip is used (encountered in Xamarin, not used by regular NativeAOT), and often ends up stack overflowing. New Xcode 15+ linker completely fails to produce correct unwind tables without this flag, which results in the NativeAOT executables crashing during GC or on first stack walk.

dotnet#471)

The flag tells the linker that there are no functions with overlapping code and thus the code sections can be divided into subsections based on the symbols. This is similar in effect to how `-ffunction-sections` behaves on ELF.

Notably, this enables optimization such as dead code stripping and identical code folding, if requested through linker switches.

Old ld64 linker tends to run into deep stack loop without this switch if `-dead_strip` is used (encountered in Xamarin, not used by regular NativeAOT), and often ends up stack overflowing. New Xcode 15+ linker completely fails to produce correct unwind tables without this flag, which results in the NativeAOT executables crashing during GC or on first stack walk.
@lambdageek
Copy link
Member Author

lambdageek commented Sep 22, 2023

DO NOT MERGE YET this is waiting for Tactics approval

@lambdageek lambdageek changed the title [ObjWriter] Emit the MH_SUBSECTIONS_VIA_SYMBOLS header flag for Mach-O [dotnet/release/8.0] [ObjWriter] Emit the MH_SUBSECTIONS_VIA_SYMBOLS header flag for Mach-O Sep 22, 2023
@lambdageek
Copy link
Member Author

Approved by tactics in email

@lambdageek lambdageek self-assigned this Sep 22, 2023
@marek-safar
Copy link

Tagging @carlossanlop

@carlossanlop
Copy link

I don't manage this repo but I can merge it if no one else has permission. This is targeting release/8.0 btw. Is that intended? I don't know if this repo has an rc2 branch.

@steveisok
Copy link
Member

I don't manage this repo but I can merge it if no one else has permission. This is targeting release/8.0 btw. Is that intended? I don't know if this repo has an rc2 branch.

We don't have an RC2 branch. It should flow into 8.0 and 8.0 rc2 where there are subscriptions.

@carlossanlop carlossanlop merged commit 2e6bfc3 into dotnet:dotnet/release/8.0 Sep 22, 2023
@lambdageek
Copy link
Member Author

Do we need to manually trigger the flow? I looked at subscriptions earlier today and I thought some of the branches were flowing weekly. Don't remember if 8.0 was one of them, however (and I'm not on a computer where I can check right now)

@steveisok
Copy link
Member

I'm monitoring the official build first to see if it passes and then I can trigger flow if necessary.

@steveisok
Copy link
Member

PR's are up in emsdk for both 8.0 branches. Once that's in, then it'll flow to runtime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants