bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc


From: Samuel Thibault
Subject: Re: x86_64-gnu 14.2.0 cross-compiler -O2 removes THREAD_SETMEM in glibc sigreturn.c
Date: Sun, 24 Nov 2024 13:16:25 +0100

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]