Hi Szabolcs, > The 10/07/2021 12:00, Lukasz Majewski wrote: > > On Thu, 7 Oct 2021 11:19:26 +0200 > > Lukasz Majewski 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