[PATCH v4 08/10] csu: Move static pie self relocation later [BZ #27072]

[H.J. Lu]

On Tue, Jan 19, 2021 at 7:32 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, Jan 19, 2021 at 7:24 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> >
> > The 01/19/2021 06:48, H.J. Lu wrote:
> > > On Tue, Jan 19, 2021 at 6:37 AM Adhemerval Zanella via Libc-alpha
> > > <libc-alpha@sourceware.org> wrote:
> > > >
> > > >
> > > >
> > > > On 19/01/2021 11:35, Szabolcs Nagy wrote:
> > > > > The 01/19/2021 11:07, Adhemerval Zanella wrote:
> > > > >> On 18/01/2021 13:25, Szabolcs Nagy via Libc-alpha wrote:
> > > > >>> IFUNC resolvers may depend on tunables and cpu feature setup so
> > > > >>> move static pie self relocation after those.
> > > > >>>
> > > > >>> It is hard to guarantee that the ealy startup code does not rely
> > > > >>> on relocations so this is a bit fragile. It would be more robust
> > > > >>> to handle RELATIVE relocs early and only IRELATIVE relocs later,
> > > > >>> but the current relocation processing code cannot do that.
> > > > >>>
> > > > >>> The early startup code before relocation processing includes
> > > > >>>
> > > > >>>   _dl_aux_init (auxvec);
> > > > >>>   __libc_init_secure ();
> > > > >>>   __tunables_init (__environ);
> > > > >>>   ARCH_INIT_CPU_FEATURES ();
> > > > >>>
> > > > >>> These are simple enough that RELATIVE relocs can be avoided.
> > > > >>>
> > > > >>> __ehdr_start may require RELATIVE relocation so it was moved
> > > > >>> later, fortunately ehdr and phdr are not used in the early code.
> > > > >>>
> > > > >>> Fixes bug 27072.
> > > > >>
> > > > >> LGTM, thanks.
> > > > >>
> > > > >> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
> > > > >
> > > > >
> > > > > sigh, this is an old version of this patch, i made a
> > > > > mistake putting the series together.
> > > > >
> > > > > the problem is that _dl_phdr is used in ARCH_SETUP_TLS
> > > > > (to get the tls program headers) so the __ehdr_start
> > > > > magic should be before that (this only matters if auxv
> > > > > lacks AT_PHDR for some reason, which should not happen
> > > > > normally on linux, so testing won't show the problem)
> > > >
> > > > By normally do you mean it might happen on a specific kernel version
> > > > or is it architecture specific?
> >
> > i guess __ehdr_start symbol can be useful and with it
> > glibc does not have to depend on auxv (which an elf
> > loader like valgrind/qemu-user may get wrong)
> >
> > however it is only used as a fallback and on linux
> > AT_PHDR is always expected to be present. (i don't
> > know if this ever triggers)
>
> Only used on Hurd?

Does arm64 linker always define __ehdr_start?  If yes, can you drop
"weak," to see if RELATIVE goes away?

> > >
> > > I think we can leave __ehdr_start ASIS since it doesn't need RELATIVE
> > > relocation.  I verified it by adding -Wl,-z,report-relative-reloc when building
> > > elf/sln on x86.
> >
> > it needs relative reloc on aarch64: it can be an undefined weak
> > symbol and that must be 0. a pc relative address computation
> > cannot give 0 (unless linker does some instruction rewriting,
> > but on aarch64 the address computation is multiple instructions
> > that can be spread far apart). so yeah it needs a GOT entry and
> > that will be either 0 or needs a RELATIVE reloc.
>
> On x86, I converted load from GOT to simple LEA without RELATIVE
> in this case.   But this is an x86 specific optimization.
>
> --
> H.J.



-- 
H.J.