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)
Tracking
()
RESOLVED
FIXED
mozilla2.0b11
People
(Reporter: glandium, Assigned: glandium)
References
Details
Attachments
(2 files)
(deleted),
patch
|
mwu
:
review+
sdwilsh
:
approval2.0+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
khuey
:
review+
sdwilsh
:
approval2.0+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•14 years ago
|
OS: Linux → Android
Assignee | ||
Comment 1•14 years ago
|
||
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 :(
Assignee | ||
Comment 2•14 years ago
|
||
In fact, it appears *all* dynamic relocations are performed a second time later on.
Assignee | ||
Updated•14 years ago
|
Summary: Fix whatever elfhack breaks on Android → Android linker assumes there is only one read-only PT_LOAD
Assignee | ||
Updated•14 years ago
|
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
Assignee | ||
Comment 3•14 years ago
|
||
Attachment #507492 -
Flags: review?(mwu)
Assignee | ||
Comment 4•14 years ago
|
||
Attachment #507493 -
Flags: review?(khuey)
Attachment #507493 -
Flags: review?(khuey) → review+
Assignee | ||
Comment 5•14 years ago
|
||
FWIW, this alone allows elfhack to work properly on current m-c. (IOW, this doesn't depend on elfhack fixes like bug 628618)
Updated•14 years ago
|
Attachment #507492 -
Flags: review?(mwu) → review+
Assignee | ||
Updated•14 years ago
|
Attachment #507492 -
Flags: approval2.0?
Assignee | ||
Updated•14 years ago
|
Attachment #507493 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #507492 -
Flags: approval2.0? → approval2.0+
Updated•14 years ago
|
Attachment #507493 -
Flags: approval2.0? → approval2.0+
Assignee | ||
Comment 6•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/ce61c1a52114
http://hg.mozilla.org/mozilla-central/rev/4949da34f21b
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b11
You need to log in
before you can comment on or make changes to this bug.
Description
•