llvm dev - Jan 2017 - Relocation Assertion error

Dear all,

I am trying to load statically linked ELF object files into an
ExecutionEngine in order to dynamically load compiled programs/libraries
into llvm generated code etc. at runtime. In order to test the general
feasibility, I am currently toying around with lli.

(1) My general idea is to use the ExecutionEngine as a wrapper to isolate
multiple instances of the same library and its symbols. To do so, I hope to
load the code into the heap, link it and run it afterwards.

(2) But I fail even to load a single instance of a test program. lli
crashes in this assertion:

https://github.com/llvm-mirror/llvm/blob/release_38/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp#L244

As far as I can tell, this test invokes a limit on the range of addresses
for relocated symbols. I am running a 64bit machine and Value is quite
large just after allocation (0x7ffff...), so I wonder if I did something
wrong when creating the object file or if there is a bug in the loader.
Could someone please shed some light on this assertion?

Also I would appreciate any hints regarding (1), has something like this
been done somewhere already? is it even possible?

thank you very much,

Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170126/85c6197e/attachment.html>

On 26 January 2017 at 08:42, Christoph Höger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> As far as I can tell, this test invokes a limit on the range of addresses
> for relocated symbols. I am running a 64bit machine and Value is quite
large
> just after allocation (0x7ffff...), so I wonder if I did something wrong
> when creating the object file or if there is a bug in the loader.  Could
> someone please shed some light on this assertion?
It sounds like the issue could be the code model. When LLVM's JIT
requests memory for your program it can get virtually any address back
from most OSs (it uses mmap or an equivalent rather than the normal
heap), but normal code is typically compiled to run from only the low
2GB of memory on x86, or to make use of dynamic-loader help so that it
can run elsewhere.

So when compiling your original static object I'd suggest some
combination of "-fPIC" (for the linker support route) and
"-mcmodel=large" (to drop the assumptions entirely). Hopefully
LLVM's
JIT can cope with those relocations, though I haven't tried it in a
while myself I'm afraid.

Tim.