On Tue, May 26, 2026 at 8:45 AM Paulo Fernando Barbosa Duarte <[email protected]> wrote: > On 24 May 2026, at 21:55, Jessica Clarke <[email protected]> wrote: > > Would it not be more appropriate to fix MIG to respect alignment > > requirements rather than hack around it by ignoring the unaligned data?
> Jessica, I investigated it and unfortunately this alignment issue cannot be > solved by MIG alone, > the current used RPC pass the data to the kernel in a byte array and the > alignment is incorrect. > I managed to add support to int __128 locally, but I would still need create > a new RPC to ensure > the alignment, the main issue is this would require to many ports in a lot of > userspace, so I > decided not to go in that direction. > Sergey your input here would also be appreciated. I don't really remember :| Jess is right that generally, fixing the underlying cause is better than adding workarounds. But in this case, thread_set_state is a generic API that is defined to work on a thread_state_t, which is an array[*:1024] of natural_t. So MIG cannot be blamed for not aligning it for int128. What I don't remember is how MIG decides whether to pass data in-line or out-of-line. Is it dependent on size (i.e. new_state_count)? And if the data is transferred out-of-line, does the kernel just get a pointer into the user's page? -- possibly unaligned? Also pay attention to thread_set_self_state, that too only does natural_t alignment. And that evidently worked for me, since sigreturn definitely restores the float registers state (see sysdeps/mach/hurd/aarch64/sigreturn.c:__sigreturn2). I wonder, does your compiler perhaps want a different alignment for __int128 than mine did? Are you (not) using aarch64-gnu-gcc? Sergey
