Update aarch64-linux-android target to match android abi.

[Nercury]

• Changed target_env to "gnu" to empty "" for all android targets because it does not matter for android.
• The PR Add integer atomic types #33048 added "max_atomic_width" for arm-android but missed recently added armv7-android. Add it there too.
• Added features +neon,+fp-armv8 because they must exist on aarch64 android.
• Update libc to include Add correctly sized structs and types for Android aarch64. libc#282 so that rust's std lib works on android's aarch64 (the main issue there was incorrect structure alignment on 64-bit arm).

r? @alexcrichton

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

Argh target_env: "gnu" was a typo, these are intended to have an empty env as they don't currently have one listed. Perhaps this could update the others instead?

Added eliminate_frame_pointer: false because the same option is also used by android's LLVM

Seems reasonable to me to follow what LLVM does here, but would be good to leave a comment as to why the option is set.

Added features +neon,+fp-armv8 because they

Is there some "official" documentation stating this as well that we could point to?

[Nercury]

Is there some "official" documentation stating this as well that we could point to?

Updated doc link to http://developer.android.com/ndk/guides/cpu-features.html, the section "64-bit ARM CPU family" mentions that FP and ASIMD (which is NEON) must be available.

[alexcrichton]

Could you add that link to the source where we specify those features? Also if you've got a link to the frame pointer business as well that'd be useful too!

[Nercury]

@alexcrichton Link added.

Also if you've got a link to the frame pointer business as well that'd be useful too!

The frame pointer business so far is just a guess. Guess that works.

[alexcrichton]

Thanks! Could you squash the commits down, and if the frame pointer elimination is still up in the air perhaps we could leave that option as the default?

[bors]

☔ The latest upstream changes (presumably #33048) made this pull request unmergeable. Please resolve the merge conflicts.

[Nercury]

leave that option as the default

what do you mean? I only saw it set for aarch64, presumably because there are problems with stack unwinding otherwise, but I might be mistaken

squash

a commit that updated liblibc got in by mistake, but do you want me to update libc as well?

[alexcrichton]

Have you observed crashes or otherwise incorrect results if frame pointers elimination is left on? I'm just thinking that if we don't have a concrete reason to turn it off we probably shouldn't, but if there's one then it's fine to turn off and we should just comment to that effect.

Ah throwing in a libc update is fine if necessary, but you can also rebase it out if you want.

[Nercury]

@alexcrichton

• Rebased on latest master, noticed that max_atomic_width was added for arm target but not armv7, so added a fix for that.
• I have checked a version of my app with and without frame pointer elimination, and there was no observable difference. This change is now excluded from the PR.
• Updating libc to latest master.

[alexcrichton]

@bors: r+ 87c90da89e9683abd50a671bbdd4e041310b2192

[bors]

⌛ Testing commit 87c90da with merge 81f9134...

[bors]

💔 Test failed - auto-linux-64-cross-netbsd

[Nercury]

Excluding latest libc commit for now because it removed libc::HW_NCPU for some reason. We will probably need to resolve it in libc.

[alexcrichton]

Hm yes that's an accident that it was removed, but we can land this in the meantime.

@bors: r+ e512abd

[bors]

⌛ Testing commit e512abd with merge 4fdf2c4...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-32cross-opt, auto-linux-64-cargotest, auto-linux-64-cross-armhf, auto-linux-64-cross-armsf, auto-linux-64-cross-freebsd, auto-linux-64-cross-netbsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-cross-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild