628233 - elhack breaks Android because linker assumes there is only one read-only PT_LOAD

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Mike Hommey [:glandium]]

When enabling elfhack on Android, it looks like it unveals a bug in the dynamic linker. I'm investigating what's wrong there, and will update this bug accordingly.

Comment 1

[Mike Hommey [:glandium]]

For the record, here is what I can see with gdb:
   0x72ccb440:	ldr	r3, [pc, #48]	; 0x72ccb478
   0x72ccb444:	lsr	r1, r0, #16
   0x72ccb448:	lsr	r2, r0, #8
   0x72ccb44c:	and	r1, r1, #255	; 0xff
   0x72ccb450:	and	r2, r2, #255	; 0xff
=> 0x72ccb454:	ldrb	r12, [r3, r1]
   0x72ccb458:	ldrb	r1, [r3, r2]
   0x72ccb45c:	and	r2, r0, #255	; 0xff
   0x72ccb460:	ldrb	r2, [r3, r2]

The arrow points to where the crash is happening. r3 is 0xe4eb6a30, r1 is 0, and there's nothing mapped at the address pointed by [r3,r1].
The value in r3 comes from 0x72ccb478, which, considering the mapping, points at VMA 0xccb478 in libxul.so. That happens to be the location of the last text relocation in libxul.so:
(...)
00ccb0a8  00000017 R_ARM_RELATIVE   
00ccb308  00000017 R_ARM_RELATIVE   
00ccb478  00000017 R_ARM_RELATIVE   
00eb1e0c  00000017 R_ARM_RELATIVE   
00eb1e10  00000017 R_ARM_RELATIVE   
(...)
.text ending at VMA 0xccb47c.

Now, following execution, this is what I can observe:
When reaching the reloc_library in linker.c, after all libraries have been mapped to memory at their final location, the content of that address is (obviously), the non relocated value 0xeb6a30, which is (also obviously) what is present in the binary.
When reaching the init function of libxul.so (iow, the beginning of the elfhack injected function), which means after relocations handled by the dynamic linker and before elfhack injected code handles its own relocations, the value at that location is 0x72eb6a30, which is correct.
After the injected code has run, the value at the location is still 0x72eb6a30, which is still correct.

And unfortunately, I can't set a watchpoint to see what is modifying that afterwards :(

Comment 2

[Mike Hommey [:glandium]]

In fact, it appears *all* dynamic relocations are performed a second time later on.

Comment 3

[Mike Hommey [:glandium]]

Attachment: part 1 - Make the Android linker stop assuming there is only one read-only PT_LOAD entry

Comment 4

[Mike Hommey [:glandium]]

Attachment: part 2 - Enable elfhack on Android

Comment 5

[Mike Hommey [:glandium]]

FWIW, this alone allows elfhack to work properly on current m-c. (IOW, this doesn't depend on elfhack fixes like bug 628618)

Comment 6

[Mike Hommey [:glandium]]

http://hg.mozilla.org/mozilla-central/rev/ce61c1a52114
http://hg.mozilla.org/mozilla-central/rev/4949da34f21b