Luca Dariz, le sam. 24 août 2024 21:09:35 +0200, a ecrit: > Il 22/08/24 23:44, Samuel Thibault ha scritto: > > Luca Dariz, le mer. 21 août 2024 18:36:14 +0200, a ecrit: > > > diff --git a/i386/include/mach/i386/mach_i386.defs > > > b/i386/include/mach/i386/mach_i386.defs > > > index 965d5c3b..61fed222 100644 > > > --- a/i386/include/mach/i386/mach_i386.defs > > > +++ b/i386/include/mach/i386/mach_i386.defs > > > @@ -111,3 +111,9 @@ routine i386_get_gdt( > > > target_thread : thread_t; > > > selector : int; > > > out desc : descriptor_t); > > > + > > > +/* Returns the size in bytes of the FPU extended state, to be used > > > + with i386_XFLOAT_STATE instead of i386_XFLOAT_STATE_COUNT */ > > > +routine i386_get_xstate_size( > > > + host : host_t; > > > + out size : natural_t); > > > > In principle that should rather be a vm_size_t? > > Yes, this was to match with thread_*_state(), which use > mach_msg_type_number_t which is a natural_t, and considering that on 64 bit > sizeof(natural_t) < sizeof(vm_size_t). > > If this makes sense, I'll document it here.
I don't know what makes most sense, I'm fine with a natural-size integer :) I don't think we'll ever be bitten by the floating-point state size being limited to a couple GBytes :) Samuel
