Re: [PATCH] add xfloat thread state interface

[Luca Dariz]

Hi,

Il 05/08/24 20:28, Sergey Bugaev ha scritto:
> On Mon, Aug 5, 2024 at 9:23 PM Samuel Thibault <samuel.thibault@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