[LLVMbugs] [Bug 15356] New: RuntimeDyldELF doesn't handle >2GB relocations on x86-64 platforms

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Mon Feb 25 15:35:32 PST 2013


http://llvm.org/bugs/show_bug.cgi?id=15356

            Bug ID: 15356
           Summary: RuntimeDyldELF doesn't handle >2GB relocations on
                    x86-64 platforms
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Generic Execution Engine Support
          Assignee: unassignedbugs at nondot.org
          Reporter: andrew.kaylor at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

On x86-64 platforms, RuntimeDyldELF cannot be guaranteed to handle 32-bit
relative relocations correctly.  Although the SectionMemoryManager attempts to
allocate all loaded sections in proximity to one another, this cannot be
guaranteed.  Furthermore, RuntimeDyldELF should not be dependent upon the
memory manager's allocation scheme to perform correctly.

The specific relocation in question is R_X86_64_PC32, which is typically used
with a call or jump instruction.  It may be possible to solve this problem by
generating a stub within the source section that can bridge the gap to the
target section.  However, some investigation is necessary to verify that this
approach will work in all cases.

Note that the assertion in the RuntimeDyldELF handler for the R_X86_64_32 and
R_X86_64_32S relocation types covers a different situation.  If that assertion
fires, it is almost certainly because code was generated with the small memory
model and is being loaded above the 2GB boundary.  When the small memory model
is used on x86-64 (not recommended), it is the responsible of the client code
to provide a memory manager which guarantees that code will be loaded below the
2GB boundary.

-- 
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/20130225/a1312879/attachment.html>


More information about the llvm-bugs mailing list