[runtime] Optionally disable inlining

[grendello]

The native runtime by default builds with function inlining enabled,
making heavy use of the feature in order to generate faster code.
However, when debugging a native crash inlining causes stack traces to
point to unlikely locations, reporting the outer function as the crash
location instead of the inlined function where crash actually happened.

In order to make such debugging easier, the XA_NO_INLINE environment
property may be exported before building the repository. This will
force all normally inlined functions to be strictly preserved and kept
separate. The generated code will be slower, but crash stack traces
should be much more precise.

Also add support for the XA_NO_STRIP variable which makes it easy
to produce runtime shared libraries with full debug symbols.

In normal builds, all the debugging information is stripped from the
runtime shared libraries, thus making stack traces rarely point to
anything more than the surrounding function name (which may sometimes be
misleading, too). The XA_NO_STRIP environment variable can be
exported before building the native runtime in order to leave the
symbols in the resulting shared library.

[jonpryor]

Usability-wise, I think I'd prefer that this be set/controlled via MSBuild properties (Configuration.Override.props) or initial make … invocation (and preserved "somewhere").

My concern is around my own usage around building my xamarin-android checkout, in which I tend to have multiple different tabs open, each with potentially different environments. I can thus see a scenario where building from one tab results in no compiler inlining, while another tab doesn't, and getting confused as to what's going on.

Using MSBuild properties would likely be as easy as updating: https://github.com/xamarin/xamarin-android/blob/cbfcc23fec533973d9340118ad8713fcc70e08b9/src/monodroid/monodroid.targets#L78

<PropertyGroup>
  <_NoInline Condition=" '$(DoNotInlineMonodroid)' == 'true' ">-DXA_NO_INLINE=true</_NoInline>
  <_NoStrip Condition=" '$(DoNotStripMonodroid)' == 'true' ">-DXA_NO_STRIP=true<_NoStrip>
  <_CmakeAndroidFlags>$(_NoInline) $(_NoStrip) --debug-output -GNinja …</_CmakeAndroidFlags>
</PropertyGroup>

[grendello]

@jonpryor I'll add the MSBuild properties, but I'll keep the environment variables as I prefer it for my workflow (make prepare all), since I don't have easy access to monodroid's msbuild properties with that.

[jonpryor]

Draft commit message:

The native runtime by default builds with function inlining enabled,
making heavy use of the feature in order to generate faster code.
However, when debugging a native crash inlining causes stack traces to
point to unlikely locations, reporting the outer function as the crash
location instead of the inlined function where crash actually happened.

In order to make such debugging easier, do one of the following:

  * Export the `XA_NO_INLINE` environment variable to "true-ish"

        export XA_NO_INLINE=1

  * Set the `$(DoNotInlineMonodroid)` MSBuild property to true,
    either by adding to `Configuration.Override.props`:

        <DoNotInlineMonodroid>true</DoNotInlineMonodroid>>

    or by specifying on the command-line:

        ./dotnet-local.sh build Xamarin.Android.sln -p:DoNotInlineMonodroid=true …

This will force all normally inlined functions to be strictly
preserved and kept separate.  The generated code will be slower, but
crash stack traces should be much more precise.

Additionally, `strip`ing of the native shared runtime can be disabled,
making it easier to get full debug symbols.  This can similarly be
enabled by doing one of the following:

  * Export the `XA_NO_STRIP` environment variable to "true-ish"

        export XA_NO_STRIP=1

  * Set the `$(DoNotStripMonodroid)` MSBuild property to true,
    either by adding to `Configuration.Override.props`:

        <DoNotStripMonodroid>true</DoNotStripMonodroid>>

    or by specifying on the command-line:

        ./dotnet-local.sh build Xamarin.Android.sln -p:DoNotStripMonodroid=true …

[jonpryor]

Part of me wonders if this should be the default behavior for Debug builds…

@grendello replied on Discord:

inlining no, I'd like the generated code to be as close to Release as possible, but we can disable stripping, sure