Mono runtime binaries need to be stripped

[akoeplinger]

This got lost with the CMake conversion, leading to e.g. the release build of libmonosgen-2.0.so for Android to be 20MB instead of 3MB.

[vargaz]

Maybe we should compile without -g in release mode ?

[rolfbjarne]

Maybe we should compile without -g in release mode ?

Not for iOS at least, you'll need the debug symbols to create the dSYM directory before stripping any binaries.

[radekdoulik]

Indeed, noticed that in apkdiff output when comparing monodroid to net6-android Release configuration apks. The net6-android's libmonosgen-2.0.so has debug sections:

Size difference in bytes ([*1] apk1 only, [*2] apk2 only):
  +  10,675,800 lib/arm64-v8a/libmonosgen-2.0.so
                  Section size difference
    +   5,038,103 .debug_info *2
    +   4,928,791 .debug_loc *2
    +   1,900,544 .debug_line *2
    +   1,000,144 .debug_ranges *2
    +     531,182 .debug_str *2
    +     272,424 .debug_frame *2
    +     190,803 .debug_abbrev *2
    +      10,008 .rela.plt
    +       9,516 .gnu.hash *2
    +       6,672 .plt
    +       6,640 .got
    +         322 .debug_macinfo *2
    +          36 .note.gnu.build-id *2
    -          16 .dynamic
    -          24 .bss
    -          82 .comment
    -         590 .gnu.version
    -       1,180 .hash
    -       2,424 .got.plt *1
    -       2,428 .data
    -       6,560 .dynstr
    -       7,080 .dynsym
    -      10,056 .data.rel.ro
    -      10,920 .rela.dyn
    -     397,734 .rodata
    -   2,660,688 .text

[jonpryor]

There is an argument to be made that no .so files should be shipped as strip'd binaries, so that when a SIGSEGV occurs, there is a way to get an environment to repeat the crash and get debug symbols from the crash.

Under this worldview, strip or equivalent should be done as late as possible, e.g. during Android .apk generation.

Alternatively, the package containing the mono runtime binaries could ship with two sets of binaries: one strip'd, one not. This is what Xamarin.Android does, shipping e.g.

• /Library/Frameworks/Xamarin.Android.framework/Versions/11.1.0.17/lib/xamarin.android/xbuild/Xamarin/Android/lib/armeabi-v7a/libmonosgen-2.0.so
• /Library/Frameworks/Xamarin.Android.framework/Versions/11.1.0.17/lib/xamarin.android/xbuild/Xamarin/Android/lib/armeabi-v7a/libmonosgen-2.0.d.so

The .d.so is the "debug" un-strip'd library. We'll use the .d.so variants when $(_AndroidDebugNativeLibraries)=True.

However, what we could instead do is (optionally) strip all .so files at .apk creation time. This would allow everyone to ship un-strip'd binaries, permitting easier debugging for all involved, while allowing customers to get smaller .apk sizes for Release builds.

[jonpryor]

Rephrased: with .NET 6, Xamarin.Android will need a way to get an un-strip'd libmonosgen-2.0.so into the .apk, so that when an app crashes, we can get a decent stack trace.

What should that mechanism be?

As previously suggested, if the NuGet package containing the mono runtime binaries is not strip'd -- meaning this issue is a no-op -- then we have an answer: use the libmonosgen-2.0.so file in the "normal" NuGet package.

If you do strip libmonosgen-2.0.so, then we'll need to have some alternate mechanism to obtain the un-strip'd binaries.

[directhex]

The "normal" behaviour here in the dotnet world is stripped libs (.dylib, .so) go into a runtime.nupkg, and both stripped libs and the stripped symbol companion files (.dwarf, .dbg) go into a runtime.symbols.nupkg file. That's what happens with coreclr, and the native pieces like libSystem.Native.dylib. I've made #53240 which does it to Mono too.

[steveisok]

@directhex Can we close then?