Samuel Thibault, le dim. 24 nov. 2024 12:44:00 +0100, a ecrit:
> Sergey Bugaev, le dim. 24 nov. 2024 14:35:33 +0300, a ecrit:
> > Reduced further:
> >
> > --8<------
> > struct hurd_sigstate;
> >
> > typedef struct
> > {
>
> [... the content doesn't actually matter]
>
> > unsigned int reply_port;
> > } tcbhead_t;
> >
> > void
> > __sigreturn2 (struct hurd_sigstate *ss, unsigned long *usp,
> > unsigned int sc_reply_port)
> > {
> > (* (unsigned int __seg_fs *) __builtin_offsetof (tcbhead_t,
> > reply_port) = sc_reply_port);
> >
> > #ifdef ADD_NOP
> > asm ("nop");
> > #endif
> >
> >
> > asm volatile ("movq %0, %%rsp\n"
> > "retq $128" :
> > : "rm" (usp));
> >
> > __builtin_unreachable ();
> > }
> > -------->8---
>
> Could it be simply because __builtin_unreachable tells gcc that the
> function is not supposed to actually execute, just because it doesn't
> know that the retq asm snippet is indeed a noreturn? Can we tell gcc
> that?
Sergey points me at
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Goto-Labels
“
GCC assumes that asm execution falls through to the next statement (if
this is not the case, consider using the __builtin_unreachable intrinsic
after the asm statement)
”
so it's the documented way to make it so, but apparently it does more
than this and affects the fs-segmented store.
Samuel
