Closed Bug 628233 Opened 14 years ago Closed 14 years ago

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

Categories

(Core :: General, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b11

People

(Reporter: glandium, Assigned: glandium)

References

Details

Attachments

(2 files)

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.
OS: Linux → Android
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 :(
In fact, it appears *all* dynamic relocations are performed a second time later on.
Summary: Fix whatever elfhack breaks on Android → Android linker assumes there is only one read-only PT_LOAD
Summary: Android linker assumes there is only one read-only PT_LOAD → elhack breaks Android because linker assumes there is only one read-only PT_LOAD
Attachment #507493 - Flags: review?(khuey)
FWIW, this alone allows elfhack to work properly on current m-c. (IOW, this doesn't depend on elfhack fixes like bug 628618)
Attachment #507492 - Flags: review?(mwu) → review+
Attachment #507492 - Flags: approval2.0?
Attachment #507493 - Flags: approval2.0?
Attachment #507492 - Flags: approval2.0? → approval2.0+
Attachment #507493 - Flags: approval2.0? → approval2.0+
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
Depends on: 637243
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: