This threads SectionName through the allocateCodeSection/allocateDataSection APIs, both in C++ and C land.  
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

FIXME: Would it be responsible to provide GOT?
llvm-svn: 188855

- 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

the JIT object (including XFAIL an ARM test that now needs fixing). Also renames
internal function for consistency.

llvm-svn: 182085

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

llvm-svn: 181354

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

llvm-svn: 173712

FIXME: It could be generalized in MemoryManager.
llvm-svn: 173349

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

XFAIL(s) can be removed.

llvm-svn: 168282

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

llvm-svn: 167164

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 committed on behalf of Kirill Uhanov

llvm-svn: 164831

Patch from Amara Emerson.

llvm-svn: 164296

llvm-svn: 163979

llvm-svn: 163354

llvm-svn: 163276

llvm-svn: 163228

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