Fix alignment of uc_mcontext in ucontext_t on arm64 android

[CUB3D]

On ARM64 Android there should be padding between uc_sigmask and uc_mcontext in libc::ucontext_t, see here

Now core::mem::offset_of!(libc::ucontext_t, uc_mcontext) is the expected value of 0xB0

fixes #3655

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @tgross35 (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[tgross35]

Thanks! Does [u8; 1024 / 8 - size_of::<sigset_t>()] work here to mirror the source? The field also needs to be public, otherwise this isn't possible to construct (I suspect there will be a CI error edit: nevermind, we don't run aarch64 android).

[CUB3D]

Thanks! Does [u8; 1024 / 8 - size_of::<sigset_t>()] work here to mirror the source? The field also needs to be public, otherwise this isn't possible to construct (I suspect there will be a CI error edit: nevermind, we don't run aarch64 android).

Apparently it does! Also fixed the visibility, although you still won't be able to construct a ucontext_t because of the sigset_t

[tgross35]

Thanks!

Since this is a fix to a tier 2 target, it should be okay to backport.

@rustbot label +stable-nominated

[tgross35]

Hey @maurer would you mind sanity checking this? I was going to backport it but figure it is worth double checking since this is a breaking change.

[maurer]

tl;dr: Change is fine, but I think we have this bug for aarch64 on base Linux, and need to update riscv as well in the same places, am I missing something?

This both seems correct and should be safe to backport, but I think it's actually incomplete.

For Android, this is also the case in riscv - we should probably add it to the rust-side riscv

However, I think this may be even worse - I checked the Linux headers for an unmodified upstream kernel - they also have this padding, but our aarch64-linux implementation currently doesn't.