Re: GCC miscompilation with __seg_fs

[Sergey Bugaev <bugaevc@gmail.com>]

On Mon, Mar 13, 2023 at 6:45 PM Jakub Jelinek <jakub@redhat.com> wrote:
> You could also hide the fact that it is based on 0 pointer from the
> compiler...

But how would you do that? If we want the generated assembly to say
%fs:0, the compiler needs to statically const-propagate the pointer to
zero. If that's not important, this seems to do the trick:

static inline size_t
zero (void)
{
  size_t res;
  asm ("xor %0, %0" : "=r" (res));
  return res;
}

#define THREAD_SELF_HIDDEN                                     \
  (*(tcbhead_t * __seg_fs *) zero ())

void
assign_through_self_hidden (void)
{
  THREAD_SELF_HIDDEN->some_member = 42;
}
// assign_through_self_hidden:
//         xor %rax, %rax
//         movq    %fs:(%rax), %rax
//         movl    $42, 8(%rax)
//         ret

FWIW, without __seg_fs (where dereferencing a zero ptr is actual UB),
assigning through *(int *) 0 is enough for GCC to consider the rest of
the code dead, whereas an assignment through **(int **) 0 does not
trigger that, but the store is still eliminated:

void some_external_call (void);

void
deref_nullptr (void)
{
  *(int *) 0 = 42;
  some_external_call ();
}
// deref_nullptr:
//         movl    $0, 0
//         ud2

void
indirect_deref_nullptr (void)
{
  **(int **) 0 = 42;
  some_external_call ();
}
// indirect_deref_nullptr:
//         jmp     some_external_call

> Feel free to file a bug report in GCC bugzilla, but that won't improve
> anything on the already released compilers.

I don't even have a GCC bugzilla account, so please file it yourself.
But yes, this needs to be worked around in glibc in any case.

Sergey