I believe the bot failures on linux systems were due to overestimating the
alignment of object-files within archives, which are only guaranteed to be
two-byte aligned. I have reduced the alignment in
RuntimeDyldELF::createObjectImageFromFile accordingly.
llvm-svn: 198737
- Mark tests as XFAIL:cygming in test/ExecutionEngine/MCJIT/remote.
Rather to suppress them, I'd like to leave them running as XFAIL.
- Revert r193472. RecordMemoryManager no longer resolves __main on cygming.
There are a couple of issues.
- X86 Codegen emits "call __main" in @main for targeting cygming.
It is useless in JIT. FYI, tests are passing when emitting __main is disabled.
- Current remote JIT does not resolve any symbols in child context.
FIXME: __main should be disabled, or remote JIT should resolve __main.
llvm-svn: 193498
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.
llvm-svn: 192514
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.
llvm-svn: 191843
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).
llvm-svn: 191804
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.
llvm-svn: 191722
- 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>
llvm-svn: 185197
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.
llvm-svn: 182209
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.
llvm-svn: 181820
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.
llvm-svn: 177988
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.
llvm-svn: 177971
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.
llvm-svn: 176057
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.
llvm-svn: 171366
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.
llvm-svn: 169252
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.
llvm-svn: 168722
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.
llvm-svn: 167400
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
llvm-svn: 163216
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.
llvm-svn: 162803
It's more flexible for MCJIT tasks, in addition it's provides a invalidation instruction cache for code sections which will be used before JIT code will be executed.
llvm-svn: 156933
Also refactor the existing OProfile profiling code to reuse the same interfaces with the VTune profiling code.
In addition, unit tests for the profiling interfaces were added.
This patch was prepared by Andrew Kaylor and Daniel Malea, and reviewed in the llvm-commits list by Jim Grosbach
llvm-svn: 152620
the X86 asmparser to produce ranges in the one case that was annoying me, for example:
test.s:10:15: error: invalid operand for instruction
movl 0(%rax), 0(%edx)
^~~~~~~
It should be straight-forward to enhance filecheck, tblgen, and/or the .ll parser to use
ranges where appropriate if someone is interested.
llvm-svn: 142106
- Introduce JITDefault code model. This tells targets to set different default
code model for JIT. This eliminates the ugly hack in TargetMachine where
code model is changed after construction.
llvm-svn: 135580
(including compilation, assembly). Move relocation model Reloc::Model from
TargetMachine to MCCodeGenInfo so it's accessible even without TargetMachine.
llvm-svn: 135468
Now we can remove RuntimeDyld from the LLVM_LINK_COMPONENTS of
tools/lli. CMakeLists.txt LLVM_LINK_COMPONENTS shall not differ from
its companion Makefile LINK_COMPONENTS.
llvm-svn: 128069
Proof-of-concept code that code-gens a module to an in-memory MachO object.
This will be hooked up to a run-time dynamic linker library (see: llvm-rtdyld
for similarly conceptual work for that part) which will take the compiled
object and link it together with the rest of the system, providing back to the
JIT a table of available symbols which will be used to respond to the
getPointerTo*() queries.
llvm-svn: 127916
llc.cpp also defined these flags, meaning that when I linked all of LLVM's
libraries into a single shared library, llc crashed on startup with duplicate
flag definitions. This patch passes them through the EngineBuilder into
JIT::selectTarget().
llvm-svn: 95390
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
llvm-svn: 94686
missing ones are libsupport, libsystem and libvmcore. libvmcore is
currently blocked on bugpoint, which uses EH. Once it stops using
EH, we can switch it off.
This #if 0's out 3 unit tests, because gtest requires RTTI information.
Suggestions welcome on how to fix this.
llvm-svn: 94164
http://llvm.org/PR5184, and beef up the comments to describe what both options
do and the risks of lazy compilation in the presence of threads.
llvm-svn: 85295
forcing them down into various .cpp files.
This change also:
1. Renames TimeValue::toString() and Path::toString() to ::str()
for similarity with the STL.
2. Removes all stream insertion support for sys::Path, forcing
clients to call .str().
3. Removes a use of Config/alloca.h from bugpoint, using smallvector
instead.
4. Weans llvm-db off <iostream>
sys::Path really needs to be gutted, but I don't have the desire to
do it at this point.
llvm-svn: 79869
out of memory, and also make the default memory manager allocate more memory
when it runs out.
Also, switch function stubs and global data over to using the BumpPtrAllocator.
This makes it so the JIT no longer mmaps (or the equivalent on Windows) 16 MB
of memory, and instead allocates in 512K slabs. I suspect this size could go
lower, especially on embedded platforms, now that more slabs can be allocated.
llvm-svn: 76828
- Otherwise we get two regressions in llvm-test for applications which run out
of space.
- Once the JIT memory manager is improved, this can be switched back.
llvm-svn: 76291
library to tell it the addresses of JITted functions. For a
particular program, this changes the opreport -l output from:
samples % image name symbol name
48182 98.9729 anon (tgid:19412 range:0x7f12ccaab000-0x7f12cdaab000) anon (tgid:19412 range:0x7f12ccaab000-0x7f12cdaab000)
11 0.0226 libstdc++.so.6.0.9 /usr/lib/libstdc++.so.6.0.9
to:
samples % image name symbol name
24565 60.7308 19814.jo fib_left
15365 37.9861 19814.jo fib_right
22 0.0544 ld-2.7.so do_lookup_x
llvm-svn: 75279
emitted or the machine code for a function is freed. Chris mentioned that we
may also want a notification when a stub is emitted, but that'll be a future
change. I intend to use this to tell oprofile where functions are emitted and
what lines correspond to what addresses.
llvm-svn: 74157
reading bytecode.
2. The interpreter can delete the ModuleProvider and replace it with
another so don't depend on it being around after the EE is created.
3. Don't just run llvm_shutdown on exit but actually delete the EE as well.
This cleans up a vast amount of memory (but not all) that EE retained
through exit.
llvm-svn: 34888
api's look like this:
ModuleProvider *getBytecodeModuleProvider(
const std::string &Filename, ///< Name of file to be read
BCDecompressor_t *BCDC = Compressor::decompressToNewBuffer,
std::string* ErrMsg = 0, ///< Optional error message holder
BytecodeHandler* H = 0 ///< Optional handler for reader events
);
This is ugly, but allows a client to say:
getBytecodeModuleProvider("foo", 0);
If they do this, there is no dependency on the compression libraries, saving
codesize.
llvm-svn: 34012
Add support for running static ctor/dtors that aren't handled by __main.
This fixes programs with the JIT and the new CFE, such as HBD.
llvm-svn: 26620
pointer marking the end of the list, the zero *must* be cast to the pointer
type. An un-cast zero is a 32-bit int, and at least on x86_64, gcc will
not extend the zero to 64 bits, thus allowing the upper 32 bits to be
random junk.
The new END_WITH_NULL macro may be used to annotate a such a function
so that GCC (version 4 or newer) will detect the use of un-casted zero
at compile time.
llvm-svn: 23888
* Place a try/catch block around the entire tool to Make sure std::string
exceptions are caught and printed before exiting the tool.
* Make sure we catch unhandled exceptions at the top level so that we don't
abort with a useless message but indicate than an unhandled exception was
generated.
llvm-svn: 19192
Move include/Config and include/Support into include/llvm/Config,
include/llvm/ADT and include/llvm/Support. From here on out, all LLVM
public header files must be under include/llvm/.
llvm-svn: 16137
* Inline callMain function
* Remove hack from the ExecutionEngines where the 'run' method would automatically
run atExit functions. Fixing this requires explicitly calling exit if main returns
llvm-svn: 10611
Lang Hames