http://llvm.org/bugs/show_bug.cgi?id=16002
Bug ID: 16002
Summary: RuntimeDyld generates incorrect Stub Functions on Arm
Product: new-bugs
Version: trunk
Hardware: Other
OS: other
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
On arm (tested on android) when generating stub functions for relocation.
RuntimeDyldImpl::createStubFunction the ldr instruction is generated, and then
the next instruction is designed to be the address in question.
So the intent is to have something like this (if my debugging is correct)
ldr [pc, pc+4]
0xdeadbeef //Address in question
So that we jump to the location
But when we actually go to resolve that address "resolveARMRelocation" we get
into ELF::R_ARM_ABS32 and simple Add Value to this address.
Since it was never initialized (unless your memory allocator did it), we are
just adding Value to some unknown value
I think this is the correct solution, although you could also have
resolveARMRelocation just set the value (since I do not think there are any
valid ARM instructions that you could add a 32-bit value to, and get a
legitimate instruction)
Index: RuntimeDyld.cpp
===================================================================
--- RuntimeDyld.cpp (revision 181708)
+++ RuntimeDyld.cpp (working copy)
@@ -363,7 +363,9 @@
// and stubs for branches Thumb - ARM and ARM - Thumb.
uint32_t *StubAddr = (uint32_t*)Addr;
*StubAddr = 0xe51ff004; // ldr pc,<label>
- return (uint8_t*)++StubAddr;
+ StubAddr++;
+ *StubAddr=0;
+ return (uint8_t*)StubAddr;
} else if (Arch == Triple::mipsel || Arch == Triple::mips) {
uint32_t *StubAddr = (uint32_t*)Addr;
// 0: 3c190000 lui t9,%hi(addr).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
