Hi,
Il 05/08/24 20:28, Sergey Bugaev ha scritto:
On Mon, Aug 5, 2024 at 9:23 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote:
Luca Dariz, le lun. 05 août 2024 14:52:24 +0200, a ecrit:
Il 05/08/24 00:32, Samuel Thibault ha scritto:
Luca Dariz, le ven. 02 août 2024 17:32:34 +0200, a ecrit:
+#define XFP_STATE_BYTES (sizeof (struct i386_xfp_save))
That is not sufficient: depending on the sse level and the saving style,
we have various amount of data to store. See fp_xsave_size computed in
init_fpu, we have to save all of that. We thus have to make get_state
check that the user-land buffer is large enough for that. And as I
mentioned on irc, the i386_xfloat_state stucture should contain the
fp_save_kind for glibc to know how to restore it.
Right, maybe we also need a way for userspace to discover the required size?
e.g. with a separate call i386_get_xstate_size().
I was thinking that perhaps glibc can compute it itself with cpuid, but
it'll be simpler to add some call to gnumach indeed.
Samuel
I haven't looked closely, but just a quick reminder that MIG can
return variable-sized data just fine, and the caller (glibc) will then
learn the size after having received the data.
The machine_thread_all_state abstraction (that glibc uses internally)
does make this somewhat awkward though.
AFAIK in thread_get_state() the caller needs to allocate enough space in
any case, even if the exact amount is not known, as handling
MIG_ARRAY_TOO_LARGE would lead to a partial state save. We could check
if there is an upper bound on this, but it might result in more
maintenance work if in the future the extended state is increased to a
bigger size.
Retrieving the amount with an arch-specific call, we only need to handle
this in gnumach (my understanding is that glibc just needs to save and
restore the xfp state, without inspecting it, during signal handling).
Luca
