This fixes a problem from a previous check-in where a return value was omitted.
Previously the remote/stubs-remote.ll and remote/stubs-sm-pic.ll tests were reporting passes, but they should have been failing. Those tests attempt to link against an external symbol and remote symbol resolution is not supported. The old RemoteMemoryManager implementation resulted in local symbols being used for resolution and the child process crashed but the test didn't notice. With this check-in remote symbol resolution fails, and so the test (correctly) fails.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192514 91177308-0d34-0410-b5e6-96231b3b80d8
At this time only Unix-based systems are supported. Windows has stubs and should re-route to the simulated mode.
Thanks to Sriram Murali for contributions to this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191843 91177308-0d34-0410-b5e6-96231b3b80d8
It's useful for the memory managers that are allocating a section to know what the name of the section is.
At a minimum, this is useful for low-level debugging - it's customary for JITs to be able to tell you what
memory they allocated, and as part of any such dump, they should be able to tell you some meta-data about
what each allocation is for. This allows clients that supply their own memory managers to do this.
Additionally, we also envision the SectionName being useful for passing meta-data from within LLVM to an LLVM
client.
This changes both the C and C++ APIs, and all of the clients of those APIs within LLVM. I'm assuming that
it's safe to change the C++ API because that API is allowed to change. I'm assuming that it's safe to change
the C API because we haven't shipped the API in a release yet (LLVM 3.3 doesn't include the MCJIT memory
management C API).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191804 91177308-0d34-0410-b5e6-96231b3b80d8
Tests to follow.
PIC with small code model and EH frame handling will not work with multiple modules. There are also some rough edges to be smoothed out for remote target support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191722 91177308-0d34-0410-b5e6-96231b3b80d8
- warn users when -debug-ir is used with old JIT engine (only partial debug
info is available)
For example, to debug an IR file with GDB (that supports JIT registration), do:
$ gdb --args lli -use-mcjit -debug-ir testcase.ll
(gdb) break main
(gdb) run
<Process continues to lli main>
(gdb) continue
<Process continues to testcase.ll main()
(gdb) step
<Now stepping through the LLVM IR in testcase.ll>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185197 91177308-0d34-0410-b5e6-96231b3b80d8
On 32-bit hosts %p can print garbage when given a uint64_t, we should
use %llx instead. This only affects the output of the debugging text
produced by lli.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182209 91177308-0d34-0410-b5e6-96231b3b80d8
the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182085 91177308-0d34-0410-b5e6-96231b3b80d8
EngineBuilder interface required a JITMemoryManager even if it was being used
to construct an MCJIT. But the MCJIT actually wants a RTDyldMemoryManager.
Consequently, the SectionMemoryManager, which is meant for MCJIT, derived
from the JITMemoryManager and then stubbed out a bunch of JITMemoryManager
methods that weren't relevant to the MCJIT.
This patch fixes the situation: it teaches the EngineBuilder that
RTDyldMemoryManager is a supertype of JITMemoryManager, and that it's
appropriate to pass a RTDyldMemoryManager instead of a JITMemoryManager if
we're using the MCJIT. This allows us to remove the stub methods from
SectionMemoryManager, and make SectionMemoryManager a direct subtype of
RTDyldMemoryManager.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181820 91177308-0d34-0410-b5e6-96231b3b80d8
that work on the LLVMBuild based dependency specification didn't
actually work, we just now maintain dependencies in *3* places instead
of 2. Yay.
There may still be some missing dependencies, I'm still sifting through
the bots and my builds, but this is a step in the right direction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177988 91177308-0d34-0410-b5e6-96231b3b80d8
its own library. These functions are bridging between the bitcode reader
and the ll parser which are in different libraries. Previously we didn't
have any good library to do this, and instead played fast and loose with
a "header only" set of interfaces in the Support library. This really
doesn't work well as evidenced by the recent attempt to add timing logic
to the these routines.
As part of this, make them normal functions rather than weird inline
functions, and sink the implementation into the library. Also clean up
the header to be nice and minimal.
This requires updating lots of build system dependencies to specify that
the IRReader library is needed, and several source files to not
implicitly rely upon the header file to transitively include all manner
of other headers.
If you are using IRReader.h, this commit will break you (the header
moved) and you'll need to also update your library usage to include
'irreader'. I will commit the corresponding change to Clang momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177971 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the RecordingMemoryManager in lli to use mapped memory rather than malloc to allocate memory for sections and uses a 'near' MemoryBlock to keep the allocations together. This works around a problem in MCJIT where relocations are applied to a generated image immediately oupon generation, which isn't appropriate for the remote case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176057 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169252 91177308-0d34-0410-b5e6-96231b3b80d8
The functionality of SectionMemoryManager is equivalent to the LLIMCJITMemoryManager being replaced except that it allocates memory as RW and later changes it to RX or R as needed. The page permissions are set in the call to MCJIT::finalizeObject.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168722 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to this patch RuntimeDyld attempted to re-apply relocations every time reassignSectionAddress was called (via MCJIT::mapSectionAddress). In addition to being inefficient and redundant, this led to a problem when a section was temporarily moved too far away from another section with a relative relocation referencing the section being moved. To fix this, I'm adding a new method (finalizeObject) which the client can call to indicate that it is finished rearranging section addresses so the relocations can safely be applied.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167400 91177308-0d34-0410-b5e6-96231b3b80d8
MCJIT supports inline assembly, but requires the asm parser to do so.
Make sure to link it in and initialize it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167392 91177308-0d34-0410-b5e6-96231b3b80d8
Simulate a remote target address space by allocating a seperate chunk of
memory for the target and re-mapping section addresses to that prior to
execution. Later we'll want to have a truly remote process, but for now
this gets us closer to being able to test the remote target
functionality outside LLDB.
rdar://12157052
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163216 91177308-0d34-0410-b5e6-96231b3b80d8
Invalidate the instruction cache right before we start actually executing code, otherwise
we can miss some that came later. This is still not quite right for a truly lazilly
compiled environment, but it's closer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162803 91177308-0d34-0410-b5e6-96231b3b80d8
