Re: [PATCH] add xfloat thread state interface

[Sergey Bugaev]

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.

Sergey