NativeAOT produces static library that makes ld crash #88032
Comments
ghost
added
the
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsDescriptionNativeAOT produces static library that makes ld crash. Reproduction StepsThis is rather complicated, it would mean checking out the branch here: xamarin/xamarin-macios#18489, and building the monotouch-test test for NativeAOT locally. If needed, I can help with that, but hopefully I can give enough info to avoid having to do this. Repro for the ld crash with the binaries from NativeAOT: https://www.dropbox.com/scl/fi/ptop654nghf40cwmd8t0r/repro.zip?dl=0&rlkey=1mub7w2c94dfayvrkfvc51vn6 Just execute ./test.sh to reproduce. The zip file also contains a binlog and the rsp file for ILC. Crash report for ld: https://gist.github.com/rolfbjarne/acd543f3386341192258ca96aa368541 Expected behaviorNo crash. Actual behavior
Regression?Yes. This started happening in this maestro bump: xamarin/xamarin-macios#18489 Which has this range for dotnet/runtime: 76da696...3195fbb Known WorkaroundsDon't pass -dead_strip to the native linker. ConfigurationNo response Other informationNo response
|
|
Looks like this regression is not in the P6 branch, only main (it doesn't reproduce in this PR: xamarin/xamarin-macios#18497) That means it's probably somewhere in this range: edfe491...3195fbb |
|
We got another bump, and the crash is gone, so seems like this was fixed. |
|
I am reopening this issue as I have experienced the same native linker crash when building Additionally, I confirm that the workaround of not passing I will try to provide more context, but it seems the issue is triggered when compiling bigger applications. /cc: @filipnavara @akoeplinger |
|
I did a simple test on empty app ( With This is basically the upper limit on the savings. It will be less for real-world app that uses more of the runtime features. I think it's acceptable to disable I also diffed the list of preserved symbols. I noticed that there's plenty of code in both the NativeAOT and Xamarin runtime that's never going to be used. We should eventually go through the list and remove the unused methods entirely. In the case of Xamarin runtime some of the unused methods date back all the way to legacy Xamarin/Mono and they are never used on .NET 6+ (eg. |
Measuring the effect on the With |
#18553) This PR disables passing `-dead_strip` to the native linker in case of NativeAOT runtime to prevent build failures. Additionally, this change affects the size of the application in the following way - measured with `dotnet new maui` app version `8.0.0-preview.7.23359.1`: | MAUI iOS | -dead_strip | no -dead_strip | diff (b) | diff (Kb) | diff (%) | |----------|--------------|----------|----------|-----------|----------| | .ipa (b) | 13377583 | 13435276 | 57693 | 57,693 | 0,43% | | Size on disk (b) | 41883897 | 42038873 | 154976 | 154,976 | 0,37% | | binary (b) | 39614336 | 39769312 | 154976 | 154,976 | 0,39% | Even though the size of the application regresses, with this change we have a more stable product. Finally, once this PR gets merged we can open a tracking issue to solve the size regression either by fixing: - dotnet/runtime#88032 or - by manually removing the dead code as proposed by @filipnavara here: dotnet/runtime#88032 (comment) --- Fixes: #18552
|
Looking at https://opensource.apple.com/source/cctools/cctools-622.5.1/RelNotes/CompilerTools.html?txt it seems like object files need to be recompiled with toolchains that understand the dead_strip optimization. I wonder if the problem is that LLVM is generating the object file in a way that looks compatible with dead_strip and then it isn't because we don't know what the proprietary magic sauce is. I assume the dead_strip is getting passed on Xamarin side since I don't see it in our .targets. |
Yes, that is correct and as a workaround it got disabled via: xamarin/xamarin-macios#18553 However, the end goal is to be able to use the flag during linking (tracked by: xamarin/xamarin-macios#18605) as it can have a significant impact with projects that use third-party bindings. /cc: @rolfbjarne |
Correct. In one case I saw an app go from >1gb to 40mb by using -dead_strip. |
|
Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos Issue DetailsDescriptionNativeAOT produces static library that makes ld crash. Reproduction StepsThis is rather complicated, it would mean checking out the branch here: xamarin/xamarin-macios#18489, and building the monotouch-test test for NativeAOT locally. If needed, I can help with that, but hopefully I can give enough info to avoid having to do this. Repro for the ld crash with the binaries already built from NativeAOT: https://www.dropbox.com/scl/fi/ptop654nghf40cwmd8t0r/repro.zip?dl=0&rlkey=1mub7w2c94dfayvrkfvc51vn6 Just execute ./test.sh to reproduce. The zip file also contains a binlog and the rsp file for ILC. Crash report for ld: https://gist.github.com/rolfbjarne/acd543f3386341192258ca96aa368541 Expected behaviorNo crash. Actual behavior
Regression?Yes. This started happening in this maestro bump: xamarin/xamarin-macios#18489 Which has this range for dotnet/runtime: 76da696...3195fbb Known WorkaroundsDon't pass -dead_strip to the native linker. ConfigurationNo response Other informationNo response
|
|
I've added the os-ios label to get this off our team's .NET 8 queries since this looks iOS specific - I'll leave this up to you if this is .NET 8 or 9. It's unlikely our team will have time to look at mystery linker crashes that require a mac to repro. If I was investigating this, I would start with why the linker even thinks the objects produced by ILC are eligible for dead_strip. It's possible LLVM is injecting something into the object files on our behalf. It wouldn't be first such thing. |
|
I am not necessarily sure that the dead-stripability of the object file is what matters here (the algorithm in ld64 is recursive and just runs out of stack space). That said, it is controlled by the |
…ault (#20796) ### Description NativeAOT now properly marks all symbols as non-deadstrippable in the object file it generates: dotnet/runtime@d9a6607 And uses `-dead_strip` as the default build option. In this PR we are doing the same - reenabling the `-dead_strip` as the default platform linker switch. This reverts previous workaround introduced in: f212f6b ### Size savings | MySingleView | Main | This PR | diff (%) | |--------------|------|---------|----------| | SOD (MB) | 2,87 | 2,70 | -5,99% | |,ipa (MB) | 1,22 | 1,17 | -4,61% | Even though this brings `4-5%` size reduction for a MySingleView app, the size savings are not proportional to the app size, as the savings are coming from stripping native libraries only. Based on measurements reported in dotnet/runtime@d9a6607 the actual expected savings for a MAUI app are around `~1.5%`. --- Fixes #18605 and dotnet/runtime#88032 --------- Co-authored-by: Ivan Povazan <[email protected]>
|
This does not seem to be reproducible anymore according to: xamarin/xamarin-macios#20796 |
Description
NativeAOT produces static library that makes ld crash.
Reproduction Steps
This is rather complicated, it would mean checking out the branch here: xamarin/xamarin-macios#18489, and building the monotouch-test test for NativeAOT locally. If needed, I can help with that, but hopefully I can give enough info to avoid having to do this.
Repro for the ld crash with the binaries already built from NativeAOT: https://www.dropbox.com/scl/fi/ptop654nghf40cwmd8t0r/repro.zip?dl=0&rlkey=1mub7w2c94dfayvrkfvc51vn6
Just execute ./test.sh to reproduce.
The zip file also contains a binlog and the rsp file for ILC.
Crash report for ld: https://gist.github.com/rolfbjarne/acd543f3386341192258ca96aa368541
Expected behavior
No crash.
Actual behavior
Regression?
Yes.
This started happening in this maestro bump: xamarin/xamarin-macios#18489
Which has this range for dotnet/runtime: 76da696...3195fbb
Known Workarounds
Don't pass -dead_strip to the native linker.
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: