[LLVMbugs] [Bug 16002] New: RuntimeDyld generates incorrect Stub Functions on Arm

[bugzilla-daemon at llvm.org]

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: unassignedbugs at nondot.org
          Reporter: andrew.woloszyn at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130514/7b7851ed/attachment.html>