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

[Szabolcs Nagy <szabolcs.nagy@arm.com>]

The 10/06/2021 13:43, Lukasz Majewski wrote:
> Please find in-depth analyze about the issue:
> 
> It was tested with Beagle Bone Black (BBB) and QEMU (the same binary
> rootfs images).
> (If needed I will upload images and script to run QEMU to some server
> for reproduction).
> Branch: https://github.com/lmajewski/y2038_glibc/commits/y2038_edge

i think it is easier to look at if you upload the broken
ld.so binary. or at least readelf -aW ld.so output.

> On working setup to trigger the core dump:
> /home/root/ld-linux-armhf.so.3 /sbin/init
> gdb ./ld-linux-armhf.so.3 core
> 
> (and the /home/root/ld-linux-armhf.so.3 is the "broken" one).
> 
> 
> Not working (patch [1] not applied):
> ====================================
> 
> All the code is located in _dl_start in elf/rtld.c and
> elf/get-dynamic-info.h files:
> 
> (gdb) p/x $r5
> $46 = 0xb6fc8000
> r5 is set from the elf_machine_load_address()
> 
> Then we enter the elf_get_dynamic_info()
> 
> 0xb6fc95fc      99            ADJUST_DYN_INFO (DT_SYMTAB);
>    0xb6fc95f8 <_dl_start+308>:  04 30 92 15     ldrne   r3, [r2, #4]
> => 0xb6fc95fc <_dl_start+312>:  05 30 83 10     addne   r3, r3, r5
>    0xb6fc9600 <_dl_start+316>:  04 30 82 15     strne   r3, [r2, #4]
> (gdb) p/x $r3
> $63 = 0x410003f4
> (gdb) p/x $r5
> $64 = 0xb6fc8000

it seems r5 is already wrong here, it's not the runtime
address of 0. (looks more like the runtime address of
0x41000000)

likely something goes wrong with the computation of r5.

> 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.

is this made by some modified binutils?