Remove _init and _fini exports from NAOT and update android docs

[am11]

@CasualPokePlayer found an alternative workaround to publish apps with latest NDK (LTS): #92272 (comment)

@josephmoresena, @LittleCodingFox, could you please confirm if this works with your setup (presumably with older NDK)? If not, we can keep both workarounds in the docs for now and later we can look into implementing small introspection to detect either-or cases in BuildIntegration to automate it.

Fixes #92272

[josephmoresena]

The last NDK I used was 26 with NativeAOT-AndroidHelloJniLib was 26, I just avoid these LinkerArg elements.
In my repo you can see:
< ItemGroup Condition="$(IsAndroid) == 'true' And $(UseLibCSections) == 'true'">
< LinkerArg Include="-Wl,--defsym,_init=__libc_init" />
< LinkerArg Include="-Wl,--defsym,_fini=__libc_fini" />
< /ItemGroup>
I don't remember until which NDK version the __libc_init and __libc_fini where exported as default.

[CasualPokePlayer]

Doing some investigation, I don't think the older workaround was appropriate at all. __libc_init has a completely different function prototype compared to _init (and __libc_init is normally just called within the _start ELF entrypoint with its expected arguments, eventually calling main).

_fini similarly has a different function prototype compared to __libc_fini (__libc_fini is just expected to be called due to it being internally registered with __cxa_atexit during the __libc_init call).

(Note however, _start won't actually be present if building as a shared library (entrypoint is just NULL, i.e. no entrypoint, no need to call __libc_init; handling other libc initialization/deinitialization is handled with other methods which aren't too relevant))

In more "standard" glibc Linux (and presumably also musl?), you'd get _init/_fini end up being implemented by parts of the libc (well, provided .o files which normally get linked in with a standard compiler setup when compiling, similar to _start). However, it just seems that this is not provided at all on bionic. Of course, user could in theory provide them and they would act the first/last ever functions called (before/after even __attribute__((constructor))/__attribute__((destructor)) implemented functions), but that's not a detail which .NET would need to really care about (well, if this is done it'd probably be in unmanaged code anyways, I doubt a C# function would work for this case).

The proper fix here is to just not put _init/_fini in the export version script at all for bionic, they don't come with bionic, no need to try to include them. It only ever appeared to work before due to clang silently ignoring them, not because they were present.

[am11]

Thanks for the further research @CasualPokePlayer, very thorough! If the signatures are mismatched, then this workaround makes more sense than the old one. I'll mark the PR ready for review.

As to the fix: @josephmoresena, since you added it the global symbols in export list (long time ago), dotnet/corert@88d7571#diff-c9020f726343209ae19211774789db0cb46bcc828f448c07ef62cb6a552b93a8R49 (current location in this repo: src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/ExportsFileWriter.cs), do you see any potential harm in deleting that line? I think it should be fine as the final linkage will take care of platform/libc specific choices.

[jkotas]

IIRC, it just would not work without that line (the global constructors/destructors would not run). If the shared libraries stil work with that line deleted, I do not see a problem with deleting it.

[am11]

@jkotas, seems like _init and _fini are not exported in case of .so, only when it is executable. Removing them from version file seems safe (init/fini are obsolete and we should be using __attribute(construction/destructor) which we are using in coreclr-pal). The published crossgen2 seems to be working after the repo build with change applied. Should I push the change in this PR?

[am11]

This can use /azp run runtime-nativeaot-outerloop checks.

[LittleCodingFox]

Thanks for the help guys, I've been busy so I can't really test this right now, but it looks like you got this!

[MichalStrehovsky]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MichalStrehovsky]

Thank you!