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

[H.J. Lu]

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.

>
> Should we turn this into a macro, so that each architecture can tweak
> this according to its needs?

Name of the macro?

> >> However, I think x86 without -mgeneral-regs-only simply is a
> >> HIDDEN_VAR_NEEDS_DYNAMIC_RELOC architecture because GCC uses dynamic
> >> relocations against hidden or static objects to load pointers into
> >> vector registers (and that's exactly what HIDDEN_VAR_NEEDS_DYNAMIC_RELOC
> >> is about).
> >
> > True only if GCC loads hidden variables into vector registers.
>
> Yes, and I think we need -mgeneral-regs-only to reliably prevent that.
>
> >> Should we build elf/rtld.c with -mgeneral-regs-only?  As far as I can
> >> see, it solves the issue, and it does not need GCC changes.
> >>
> >
> > Vector instructions are OK in rtld.c:
>
> For the most part, yes, but are they in performance-critical code?

rtld.c is used by all programs.  Every bit of performance helps.

> If we do not use -mgeneral-regs-only, there is bound to be another
> combination of compiler option that tries to load pointers directly into
> vector registers before initial self-relocation.

The list of these hidden variables is small, which can be checked by
the newly added test.

> Thanks,
> Florian
>


-- 
H.J.