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.

(moreover, IMHO running prelink on any binary and glibc is a valid use
case)

> 2) partial revert

Ok.

> 3) new way to compute the load address.

This would require some input from developers deeply involved in ELF
loader development. (Florian IIRC).

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