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

Interface changes to allow RuntimeDyld memory managers to set memory permissions after an object has been loaded.

llvm-svn: 168114

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

MCJIT supports inline assembly, but requires the asm parser to do so.
Make sure to link it in and initialize it.

llvm-svn: 167392

Patch by Ashok Thirumurthi

llvm-svn: 167192

llvm-svn: 167185

Patch by Amara Emerson.

llvm-svn: 166920

Patch by Amara Emerson.

llvm-svn: 165791

lli: [MCJIT] Suppress "__main" for cygming in LLIMCJITMemoryManager::getPointerToNamedFunction(), like legacy JITMemoryManager's.

CRT's __main (aka premain) invokes global ctors on cygming. See also PR3897.

llvm-svn: 165312

Patch from Amara Emerson.

llvm-svn: 164296

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

Found by valgrind.

llvm-svn: 157160

llvm-svn: 157118

Added LLIMCJITMemoryManager to the lli. This manager will be used for MCJIT instead of DefaultJIMMemoryManager.
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

if !ForceInterpreteri). It has no effect (apart from a memory leak...)

llvm-svn: 155792

backend flags in TargetOptions.h into their own class in r145714.

llvm-svn: 154993

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

Adding a basic ELF dynamic loader and MC-JIT for ELF. Functionality is currently basic and will be enhanced with future patches.
Patch developed by Andy Kaylor and Daniel Malea. Reviewed on llvm-commits.

llvm-svn: 148231

llvm-svn: 147970

llvm-svn: 147969

Previously let the JITEmitter do it. That's rather odd, and doesn't play nice
with the MCJIT, so move the (trivial) logic up.

llvm-svn: 147967

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

These are strictly utilities for registering targets and components.

llvm-svn: 138450

- 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

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

llvm-svn: 120298

llvm-svn: 119509

llvm-svn: 119508

 - Also, switch tests to not using llvm-as. They run 20% faster now, not that it matters.

llvm-svn: 118952

llvm-svn: 117095

they hit the rest of the system.

llvm-svn: 112344

llvm-svn: 101365

characters long.

llvm-svn: 101336

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

against both 2.6 and HEAD.  The default is still changed to eager jitting.

llvm-svn: 85330

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

default and didn't work anyway.

llvm-svn: 84720