Re: [PATCH] dl: Use "adr" assembler command to get proper load address

[Lukasz Majewski <lukma@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]

Hi Szabolcs,

> The 10/07/2021 12:00, Lukasz Majewski wrote:
> > On Thu, 7 Oct 2021 11:19:26 +0200
> > Lukasz Majewski <lukma@denx.de> wrote:  
> > > Please find working and broken ld-linux-armhf.so.3:
> > > https://owncloud.denx.de/s/wtAfktG6pXLffSA  
> 
> thanks.
> 
> i can confirm that this crashes on an aarch64 machine too
> (that supports running arm binaries), so not just a qemu
> problem.
> 
> 
> > > > > Links:
> > > > > [1] -
> > > > > https://github.com/lmajewski/y2038_glibc/commit/e67e0f589b88a44be8f8b9b770b08950dd7e5bd5
> > > > > 
> > > > > readelf -e ld-linux-armhf.so.3 
> > > > > 
> > > > > [10] .plt              PROGBITS        41000994 000994 000050
> > > > > 04 AX  0   0  4 [11] .text             PROGBITS
> > > > > 41000a00 000a00 01fed0 00  AX  0   0 64 [12] .rodata
> > > > >  PROGBITS 410208d0 0208d0 004b24 00   A  0   0  4 [13]
> > > > > .ARM.extab PROGBITS        410253f4 0253f4 000018 00   A  0
> > > > > 0  4 [14] .ARM.exidx        ARM_EXIDX       4102540c 02540c
> > > > > 0000c8 00  AL 11 0  4 [15] .data.rel.ro      PROGBITS
> > > > > 41036200 026200 000cf4 00  WA  0   0  8 [16] .dynamic
> > > > >  DYNAMIC 41036ef4 026ef4 0000c8 08  WA  5   0  4 [17] .got
> > > > > PROGBITS 41036fbc 026fbc 000040 04  WA  0   0  4      
> > > > 
> > > > why are all addresses >0x41000000 ?
> > > > in a shared library i expect all those addresses
> > > > to be close to 0.    
> > > 
> > > On this real HW system (the rootfs which is running) - libc.so.6
> > > also has address > 0x41000000
> > > libm.so.6 also has the value > 0x41200000
> > > (Entry point address:               0x412c9190)
> > > 
> > > The offset of > 0x41000000 looks a bit strange indeed, but it is
> > > still less than the kernel space. Moreover, with position
> > > independent code it shall not matter.
> > >   
> > > > 
> > > > is this made by some modified binutils?    
> > > 
> > > I've double checked the ld-linux-armhf.so.3 and after build it
> > > has: (Entry point address:               0xa00) which seems to be
> > > correct.
> > > 
> > > So it looks like during installation of the glibc (on the Yocto/OE
> > > created rootfs) the elf header is modified and this 0x41000000
> > > offset is added.
> > >   
> > 
> > And indeed it is the case. Yocto/OE by default perform prelinking
> > (use prelink program) to speedup start time of dynamic program.
> > 
> > The prelink [1] itself assigns some virtual addresses to all
> > required shared objects (in our case for /sbin/init), so no clashes
> > are encountered.
> > 
> > And using prelink is a _default_ behaviour in Yocto/OE poky distro.
> > 
> > Links:
> > [1] - https://linux.die.net/man/8/prelink  
> 
> ah prelinking.
> 
> ok so &__ehdr_start is supposed to point to the
> elf header, which supposed to start at address 0
> within the elf image.
> 
> but with prelinking everthing is moved by a fixed
> offset (including the elf header), so __ehdr_start
> is no longer has 0 address.

I think that __ehdr_start now points to > 0x41000000.

> 
> i don't immediately know what's the best fix for this.

I think that getting the address with 'adr' ASM instruction was more
robust, as it was not relying on the set constant (__ehdr_start).


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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]