On Mon, 11 Oct 2021 06:22:53 -0700
"H.J. Lu" <hjl.tools@gmail.com> wrote:

> On Mon, Oct 11, 2021 at 6:10 AM Lukasz Majewski <lukma@denx.de> wrote:
> >
> > On Mon, 11 Oct 2021 05:01:23 -0700
> > "H.J. Lu" <hjl.tools@gmail.com> wrote:
> >  
> > > On Mon, Oct 11, 2021 at 4:47 AM Lukasz Majewski <lukma@denx.de>
> > > wrote:  
> > > >
> > > > Hi Szabolcs,
> > > >
> > > > Thank you very much for your input.
> > > >  
> > > > > The 10/11/2021 10:56, Lukasz Majewski wrote:  
> > > > > > Do we have _any_ plan how to fix it? BSPs for many boards
> > > > > > are built with Yocto/OE nowadays...
> > > > > >
> > > > > > The approach with using 'adr' (pseudo) assembler
> > > > > > instruction to calculate the on-runtime addresses was
> > > > > > working previously.
> > > > > >
> > > > > > Shall we revert changes which were introduced recently (to
> > > > > > use __ehdr_start)?  
> > > > >
> > > > > the reason for the change was to avoid relying on GOT[0].  
> > > >
> > > > And why it is requested to not relying on GOT[0]?
> > > >  
> > > > >
> > > > > i guess we can revert elf_machine_load_address on arm, but
> > > > > keep the new elf_machine_dynamic that does not rely on
> > > > > GOT[0].  
> > > >
> > > > This was the approach proposed by this patch.
> > > >  
> > > > >
> > > > > it is also useful to have the same c code across targets
> > > > > for the load address. if we want to do that and support
> > > > > vaddr!=0 for ehdr then i think it can be (untested):
> > > > >
> > > > > __attribute__ ((const)) ElfW(Addr)
> > > > > load_addr (void)
> > > > > {
> > > > >   extern const ElfW(Ehdr) __ehdr_start __attribute__
> > > > > ((visibility ("hidden"))); ElfW(Addr) addr = (ElfW(Addr))
> > > > > &__ehdr_start; ElfW(Word) phnum = __ehdr_start.e_phnum;
> > > > >   const ElfW(Phdr) *phdr = (const void *) (addr +
> > > > > __ehdr_start.e_phoff); const ElfW(Phdr) *ph;
> > > > >   assert (__ehdr_start.e_phentsize == sizeof *phdr);
> > > > >   for (ph = phdr; ph < &phdr[phnum]; ++ph)
> > > > >     if (ph->p_type == PT_LOAD && ph->p_offset == 0)
> > > > >       {
> > > > >         addr -= ph->p_vaddr;  
> > > >
> > > > The above line is a bit strange for me. Isn't the p_offset set
> > > > by prelink as well?
> > > >
> > > > And most of all - why do we need to perform relocation in such
> > > > very early stage of the ld-linux-armhf.so.3 ?
> > > >  
> > > > >         break;
> > > > >       }
> > > > >   return addr;
> > > > > }
> > > > >
> > > > > i don't have a strong preference either way:
> > > > > 1) fix yocto  
> > > >
> > > > Yocto by default uses prelinkg from the very long time. I think
> > > > that it would be very difficult to change that.  
> > >
> > > Just don't run prelink on ld.so since the load address is
> > > controlled by kernel.  
> >
> > prelink is used also to speed things up. In some use cases - boot
> > time optimization (like kiosk, or automotive) the bootup time is
> > crucial.  
> 
> I am NOT asking you to remove prelink.  I am only asking not to run
> prelink on ld.so.  Do you have bootup time data on ld.so with and
> without prelink?

The prelink is run on /sbin/init binary, so the libc.so.6 and
ld-linux-armhf.so.3 are automatically affected.

To put it in other words - up till this issue everything was working
(maybe it was just working by a pure coincidence).

Now, because of change in glibc (__ehdr_start usage) you ask if
Yocto/OE can stop using prelink on certain libraries to avoid this
error.

Have I understood your comment correctly?

> 
> > IMHO, the change with __ehdr_start introduced regression and hence
> > shall be fixed so the previous behaviour is preserved.
> >  
> 




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de