linux(4): In preparation for xsave refactor fxsave code on amd64

[dchagin]

Summary

Due to fxsave area is os independent reimplement fxsave handmade code
using copying of a whole area.

Test Plan

golang and glibc test suite

[kib]

sys/x86/linux/linux_x86_sigframe.h

149

Why do you need this structure?

178

What is the purpose of this structure?

Also, is my reading correct that the structure definition is doubled? See above line 66

[dchagin]

sys/x86/linux/linux_x86_sigframe.h

149

just to preserve/restore native mcontext_t mc_ownedfp and mc_ownedfp, lines 304,423
and mc_xfpustate_len for xsave

178

What is the purpose of this structure?

part of sigframe structure, line 190, i.e., the same as native counterpart

Also, is my reading correct that the structure definition is doubled? See above line 66

No, this is common include for x86, on amd64/linux32 this structure should be packed,
well, I can guard __packed attribute by #ifdef of course

[kib]

sys/x86/linux/linux_x86_sigframe.h

149

But you should not do this. The frame saved into the user memory should exactly match the Linux layout, no FreeBSD specific fields are allowed.

178

Thanks. Perhaps #else line should get the same comment as #endif.

[dchagin]

sys/x86/linux/linux_x86_sigframe.h

149

But you should not do this. The frame saved into the user memory should exactly match the Linux layout, no FreeBSD specific fields are allowed.

I put this structure into the reserved area to bytes economy, however it’s not a problem to put it at the end of sigframe before fpstate

178

Thanks. Perhaps #else line should get the same comment as #endif.

ok, I'll fix it later

[kib]

sys/x86/linux/linux_x86_sigframe.h

149

You should not put it into Linux userspace at all.
BTW same for uc_* members of the FreeBSD ucontext_t.

They are either not needed for sigreturn(2) in any form, including Linux, or have trivial valid values you can reconstruct on fly.

[dchagin]

sys/x86/linux/linux_x86_sigframe.h

149

You should not put it into Linux userspace at all.
BTW same for uc_* members of the FreeBSD ucontext_t.

why? On Linux userspace should read sc_fpsate of sigcontext to get xsave area ptr due to strict alignment requirements for this area (Linux does not copyin/copyout xsave area, just uses op's)

They are either not needed for sigreturn(2) in any form, including Linux, or have trivial valid values you can reconstruct on fly.

I see, then what to do with the xfpusave_len? Also reconstruct?

[kib]

sys/x86/linux/linux_x86_sigframe.h

149

You should not put it into Linux userspace at all.
BTW same for uc_* members of the FreeBSD ucontext_t.

why? On Linux userspace should read sc_fpsate of sigcontext to get xsave area ptr due to strict alignment requirements for this area (Linux does not copyin/copyout xsave area, just uses op's)

Because there is no such field on Linux. I am sure that eventually there is a binary that hardcodes the layout.

They are either not needed for sigreturn(2) in any form, including Linux, or have trivial valid values you can reconstruct on fly.

I see, then what to do with the xfpusave_len? Also reconstruct?

What does Linux do there? Is it always writing the max layout? If yes, you should do the same.

[dchagin]

Done, thank you!

[kib]

sys/x86/linux/linux_x86_sigframe.h

183

So why do you still need this structure?

[dchagin]

sys/x86/linux/linux_x86_sigframe.h

183

You mean l_ucontext? This comment is located below the definition of this structure.
structs l_rt_sigframe, l_ucontext, l_sigcontext modeled like a Linux does.

if l_fpstate, in D40444 it is used as Linux put some magic value into reserved area of an xsave area

[kib]

sys/x86/linux/linux_x86_sigframe.h

183

Does Linux ucontext have all these fields like uc_link etc?

[dchagin]

sys/x86/linux/linux_x86_sigframe.h

183

sure, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/ucontext.h

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/signal_64.c#n182