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. Sergey
