[llvm-bugs] [Bug 39577] New: RuntimeDyldCOFFX86_64 does not apply mappings to the fake __ImageBase address

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39577

            Bug ID: 39577
           Summary: RuntimeDyldCOFFX86_64 does not apply mappings to the
                    fake __ImageBase address
           Product: libraries
           Version: 7.0
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Generic Execution Engine Support
          Assignee: unassignedbugs at nondot.org
          Reporter: bjoern.gaier at horiba.com
                CC: 1101.debian at gmail.com, llvm-bugs at lists.llvm.org

Currently I generate bitcode files with Clang for the target platform Windows.
These files are getting loaded and resolved by a JITClient, who will load the
files into a local memory first. Later this memory will be mapped to a shared
memory with really high addresses like 0xFFFFFA800FCC0000.

When I build this bitcode files with debug output, the relocation type will
change to 'IMAGE_REL_AMD64_ADDR32NB' and suddenly I will get a lot of errors
stating:
"IMAGE_REL_AMD64_ADDR32NB relocation requires anordered section layout."

My bitcode file is really small, so I will not run in 32bit offfset problems. I
think the problem is the following one:

In line 35 of "RuntimeDyldCOFFX86_64.h" you can read following comment:
"//Fake an __ImageBase pointer by returning the section with the lowest adress"

So when I allocate the local memory for my bitcode file, this value will be the
address of the beginng of my local memory. 
But when I do the mapping to the shared memory, the address of the 'fake
__ImageBase' will not change and suddenly I have an offset bigger then 32bit.
But 'fake __ImageBase' should change to the lowest address of my shared memory.

-- 
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/20181107/23fdacbd/attachment.html>