[PATCH v2] elf: Add optimization barrier for __ehdr_start and _end

[Alexander Monakov]

On Mon, 16 Jun 2025, H.J. Lu wrote:

> On Mon, Jun 16, 2025 at 1:48 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * H. J. Lu:
> >
> > > On Mon, Jun 16, 2025 at 12:55 PM Florian Weimer <fweimer@redhat.com> wrote:
> > >>
> > >> * H. J. Lu:
> > >>
> > >> > diff --git a/elf/rtld.c b/elf/rtld.c
> > >> > index 8e8f0e6253..e6a181dc31 100644
> > >> > --- a/elf/rtld.c
> > >> > +++ b/elf/rtld.c
> > >> > @@ -477,7 +477,10 @@ _dl_start_final (void *arg, struct dl_start_final_info *info)
> > >> >    _dl_setup_hash (&_dl_rtld_map);
> > >> >    _dl_rtld_map.l_real = &_dl_rtld_map;
> > >> >    _dl_rtld_map.l_map_start = (ElfW(Addr)) &__ehdr_start;
> > >> > +  /* Prevent run-time relocations against __ehdr_start and _end.  */
> > >> > +  asm ("" : "+g" (_dl_rtld_map.l_map_start));
> > >> >    _dl_rtld_map.l_map_end = (ElfW(Addr)) _end;
> > >> > +  asm ("" : "+g" (_dl_rtld_map.l_map_end));
> > >> >    /* Copy the TLS related data if necessary.  */
> > >> >  #ifndef DONT_USE_BOOTSTRAP_MAP
> > >> >  # if NO_TLS_OFFSET != 0
> > >>
> > >> This needs a better comment about why we are doing this, and exactly how
> > >> it prevents this problem.
> > >
> > > How about
> > >
> > > Prevent compiler vectorizer from loading hidden variables into vector registers.
> >
> > It doesn't say why "g" is the appropriate constraint here.
> 
> "+g" is the least restricted constraint.  It tells compilers that the operand
> is both input and output.

But you are applying it after the assignment into _dl_rtld_map, which is too
late.  As written, it doesn't prevent vectorization.  I think Jakub's suggestion
was to use an asm to implement a non-transparent copy of the value (before use).

It's not perfectly suitable for a macro, but it could be written like

#define NON_TRANSPARENT_COPY(val) \
  ({ __typeof(val) _result = val; asm ("" : "+r"(_result)); _result; })

and then used like

  _dl_rtld_map.l_map_start = NON_TRANSPARENT_COPY (&__ehdr_start);

(I don't see a reason to use "+g" here, we don't want the value in memory,
so "+r" seems slightly preferable)

Alexander