linux/aarch64: make mcontext_t.__reserved pub

[jstarks]

Description

The mcontext_t.__reserved field is documented to contain extra context, such as FP state and the ESR register.

Sources

• Linux uapi
• Glibc
• Musl
• Android

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are
  included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget);
  especially relevant for platforms that may not be checked in CI

@rustbot label +stable-nominated

[rustbot]

Some changes occurred in the Android module

cc @maurer

[tgross35]

Is there official documentation outside of the uapi comment saying what this field contains? The manpage I found says (link):

The mcontext_t type is machine-dependent and opaque.

Given that and the fact that the field is actually named reserved, I am hesitant to expose this. If you actually need these fields and want to opt into whatever sort of instability they have, it would be better to define your own struct and transmute.

[tgross35]

(updating status)

[jstarks]

Is there official documentation outside of the uapi comment saying what this field contains? The manpage I found says (link):

The mcontext_t type is machine-dependent and opaque.

Given that and the fact that the field is actually named reserved, I am hesitant to expose this. If you actually need these fields and want to opt into whatever sort of instability they have, it would be better to define your own struct and transmute.

The uapi header is the only documentation I am aware of. But uapi documents interfaces that are stable. I certainly agree that the __reserved name is a red flag--nonetheless, it's a guaranteed stable part of the Linux ABI and by extension the glibc/musl API. I think they're just stuck with the poor choice of name, which hasn't changed since it was introduced in 2012.

If you search around (https://github.com/search?q=__reserved+uc_mcontext&type=code), you can find lots of C/C++ code accessing this field as documented in the uapi definitions. It should be possible to port such code to Rust without manually defining types.

I suppose to really complete that promise, libc should also define _aarch64_ctx and some of the magic numbers and other types from uapi. I'd be happy to do that as well, if you think it's a good idea. musl and Android define these types in their headers but glibc does not--I would guess glibc users probably include the uapi header directly to get these definitions, but I'm not sure.