i#3699 ARM: Add padding to priv_mcontext_t for 8-byte alignment.

[egrimley-arm]

ef4482e caused a few additional failures. In particular, the child of a clone3 system call started with the register values shifted: R2 got the value that should be in R1 and so on. That caused the test linux.clone to fail.

It turns out that some callers of insert_{push,pop}_all_registers expect that an unpadded priv_mcontext_t will be pushed/popped. Moving the 4-byte padding to above the struct instead of below it makes some tests pass but breaks others. So we add some padding in the middle of priv_mcontext_t, changing its size from 324 to 328. It will probably run slightly faster with the struct (and particularly the field "simd") 8-byte aligned.

Update insert_{push,pop}_all_registers and arm.asm for the new struct layout, with some additional changes to arm.asm:

• Delete irrelevant X64 macros.

• Document the macros more clearly (they can be found with grep).

• Change SP only at start and end of function (standard practice, makes debugging easier).

• Avoid writing below SP (compatible with signal handlers).

This change breaks compatibility so the version is increased to 11.90.

Issue: #3699

[derekbruening]

This makes it sound like we appended padding to the end where a recompile is enough; but really we inserted padding in between fields, so any code such as generated machine instructions for instrumentation has to be updated as the field offsets have changed. I think this needs to explicitly say that some field offsets have changed.

[egrimley-arm]

I've improved the change log ... and I've just realised that I hadn't actually made priv_mcontext_t 8-byte aligned! I'd changed its size to a multiple of 8, and in the places where it is allocated in assembly on the stack it is 8-byte aligned because SP is 8-byte aligned, and it would be automatically 8-byte aligned if someone were to use malloc, but a priv_mcontext_t local variable might not be 8-byte aligned as it was. So I've added a uint64 _unused in an anonymous union in the struct definition. Do you think that's the thing to do and the right way to do it?

[derekbruening]

So I've added a uint64 _unused in an anonymous union in the struct definition. Do you think that's the thing to do and the right way to do it?

Use ALIGN_VAR(8).

[derekbruening]

I don't think you marked priv_mcontext_t as ALIGN_VAR, so it won't be aligned, right?

[egrimley-arm]

Yes, I may have been a bit hasty in merging that, and the change log entry is unclear: I think I honestly meant "it" to refer to the "size" when I wrote that but readers will, of course, understand "it" to refer to the struct!

Enforcing alignment seems to cause a problem with cross-compilation that I'm not yet set up to reproduce on a local machine: #7196.

We must either debug that cross-compilation problem and enforce alignment, or correct that log message to make it clear that all we have done is make the size a multiple of 8 in order to facilitate alignment.

(The cross-compilation problem seems rather interesting. If there are lingering alignment issues in the code I wonder if #7161 will turn out to be alignment-related.)