As an ExecutionEngine class function, its definition
really belongs in ExecutionEngine.cpp, not JIT.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131027 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, into EngineBuilder. This should only impact
the private API between the EE and EB classes, not external
clients, since JITCtor and MCJITCtor are both protected members.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131026 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares for making JITCtor/MCJITCtor take a
TargetMachine* directly from clients like EngineBuilder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@131025 91177308-0d34-0410-b5e6-96231b3b80d8
a bit more sinister as the memset doesn't do what the constructor does.
There seems to be a cleaner solution than a cast here though, instead we
can point the memset destination into the union its actually trying to
clear.
An alternative is to point to the Untyped member of this union. Review
appreciated, and if that is cleaner I'm happy to switch. All of these
should be functionally equivalent to the original code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130395 91177308-0d34-0410-b5e6-96231b3b80d8
Add handling for tracking the relocations on symbols and resolving them.
Keep track of the relocations even after they are resolved so that if
the RuntimeDyld client moves the object, it can update the address and any
relocations to that object will be updated.
For our trival object file load/run test harness (llvm-rtdyld), this enables
relocations between functions located in the same object module. It should
be trivially extendable to load multiple objects with mutual references.
As a simple example, the following now works (running on x86_64 Darwin 10.6):
$ cat t.c
int bar() {
return 65;
}
int main() {
return bar();
}
$ clang t.c -fno-asynchronous-unwind-tables -o t.o -c
$ otool -vt t.o
t.o:
(__TEXT,__text) section
_bar:
0000000000000000 pushq %rbp
0000000000000001 movq %rsp,%rbp
0000000000000004 movl $0x00000041,%eax
0000000000000009 popq %rbp
000000000000000a ret
000000000000000b nopl 0x00(%rax,%rax)
_main:
0000000000000010 pushq %rbp
0000000000000011 movq %rsp,%rbp
0000000000000014 subq $0x10,%rsp
0000000000000018 movl $0x00000000,0xfc(%rbp)
000000000000001f callq 0x00000024
0000000000000024 addq $0x10,%rsp
0000000000000028 popq %rbp
0000000000000029 ret
$ llvm-rtdyld t.o -debug-only=dyld ; echo $?
Function sym: '_bar' @ 0
Function sym: '_main' @ 16
Extracting function: _bar from [0, 15]
allocated to 0x100153000
Extracting function: _main from [16, 41]
allocated to 0x100154000
Relocation at '_main' + 16 from '_bar(Word1: 0x2d000000)
Resolving relocation at '_main' + 16 (0x100154010) from '_bar (0x100153000)(pcrel, type: 2, Size: 4).
loaded '_main' at: 0x100154000
65
$
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129388 91177308-0d34-0410-b5e6-96231b3b80d8
mean that it has to be ConstantArray of ConstantStruct. We might have
ConstantAggregateZero, at either level, so don't crash on that.
Also, semi-deprecate the sentinal value. The linker isn't aware of sentinals so
we end up with the two lists appended, each with their "sentinals" on them.
Different parts of LLVM treated sentinals differently, so make them all just
ignore the single entry and continue on with the rest of the list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129307 91177308-0d34-0410-b5e6-96231b3b80d8
Teach 32-bit section loading to use the Memory Manager interface, just like
the 64-bit loading does. Tidy up a few other things here and there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129138 91177308-0d34-0410-b5e6-96231b3b80d8
Start teaching the runtime Dyld interface to use the memory manager API
for allocating space. Rather than mapping directly into the MachO object,
we extract the payload for each object and copy it into a dedicated buffer
allocated via the memory manager. For now, just do Segment64, so this works
on x86_64, but not yet on ARM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128973 91177308-0d34-0410-b5e6-96231b3b80d8
The JITMemory manager references LLVM IR constructs directly, while the
runtime Dyld works at a lower level and can handle objects which may not
originate from LLVM IR. Introduce a new layer for the memory manager to
handle the interface between them. For the MCJIT, this layer will be almost
entirely simply a call-through w/ translation between the IR objects and
symbol names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128851 91177308-0d34-0410-b5e6-96231b3b80d8
The ExecutionEngine constructor already added the module, so there's no
need to call addModule() directly. Doing so causes a double-free of the
Module at program termination.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128171 91177308-0d34-0410-b5e6-96231b3b80d8
Support argument passing simple, common, prototypes directly. More
complicated scenarios will require building up a stub function, which the
MC-JIT isn't set up to handle yet.
Add Intercept.cpp, which is just a copy from ExecutionEngine/JIT for now,
to handle looking looking up external symbol names. This probably more
properly belongs as part of RuntimeDyld. It'll migrate there as things
flesh out more fully.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128090 91177308-0d34-0410-b5e6-96231b3b80d8
Lots of cleanup to make the interfaces prettier, use the JITMemoryManager,
handle multiple functions and modules, etc.. This gets far enough that
the MCJIT compiles and runs code, though.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128052 91177308-0d34-0410-b5e6-96231b3b80d8
Move the dynamic linking functionality of the llvm-rtdyld program into an
ExecutionEngine support library. Update llvm-rtdyld to just load an object
file into memory, use the library to process it, then run the _main()
function, if one is found.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@128031 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@127916 91177308-0d34-0410-b5e6-96231b3b80d8
deregisters registered by it FDE structures allowing consecutive
JIT runs to succeed. Patch by Yuri. Fixes PR8285.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117004 91177308-0d34-0410-b5e6-96231b3b80d8
On Mingw and Cygwin, the symbol __main is resolved to
callee's(eg. tools/lli) one, to invoke wrong duplicated ctors
(and register wrong callee's dtors with atexit(3)).
We expect, by callee, ExecutionEngine::runStaticConstructorsDestructors()
is called before ExecutionEngine::runFunctionAsMain() is called.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@112474 91177308-0d34-0410-b5e6-96231b3b80d8
exception handling. Also fix an extra underscore typo in one instance of
"__ARM_EABI__". Radar 8236264.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@109451 91177308-0d34-0410-b5e6-96231b3b80d8
MachineFunction::DefaultDebugLoc. We now use the same technique as
DwarfDebug::beginFunction to find the starting line number for a
function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102679 91177308-0d34-0410-b5e6-96231b3b80d8
JIT doesn't use the MC back-end asm printer to emit labels that it uses, the
section for the MCSymbol is never set. And thus the MCSymbol for the EH label
isn't marked as "defined". Because of that, TidyLandingPads removes the needed
landing pads from the JIT output. This breaks EH for every JIT program.
This is a work-around for this limitation. We pass in the label locations
map. If the label has a non-zero value, then it was "emitted" by the JIT and
TidyLandingPads shouldn't remove that label.
A nicer solution would be to mark the MCSymbol as "used" by the JIT and not rely
upon the section being set to determine if it's defined or not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@101453 91177308-0d34-0410-b5e6-96231b3b80d8
representation. This eliminates the 'DILocation' MDNodes for
file/line/col tuples from -O0 -g codegen.
This remove the old DebugLoc class, making it a typedef for DebugLoc,
I'll rename NewDebugLoc next.
I didn't update the JIT to use the new apis, so it will continue to
work, but be as slow as before. Someone should eventually do this
or, better yet, rip out the JIT debug info stuff and build the JIT
on top of MC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100209 91177308-0d34-0410-b5e6-96231b3b80d8
instead of label ID's. This cleans up and regularizes a bunch
of code and makes way for future progress.
Unfortunately, this pointed out to me that JITDwarfEmitter.cpp
is largely copy and paste from DwarfException/MachineModuleInfo
and other places. This is very sad and disturbing. :(
One major change here is that TidyLandingPads moved from being
called in DwarfException::BeginFunction to being called in
DwarfException::EndFunction. There should not be any
functionality change from doing this, but I'm not an EH expert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98459 91177308-0d34-0410-b5e6-96231b3b80d8
and add a FIXME about how we are eventually going to zap this
lookup table once mc world domination is complete.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98031 91177308-0d34-0410-b5e6-96231b3b80d8
just count references to it from JIT output to decide when to destroy it. This
patch waits to destroy the JIT's memory of a stub until the Function it refers
to is destroyed. External function stubs and GVIndirectSyms aren't destroyed
until the JIT itself is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97737 91177308-0d34-0410-b5e6-96231b3b80d8
destroyed, it could leave stubs in the StubToResolverMap, which would confuse
the lookup for subsequent lazy compilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@97698 91177308-0d34-0410-b5e6-96231b3b80d8
and T->isPointerTy(). Convert most instances of the first form to the second form.
Requested by Chris.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@96344 91177308-0d34-0410-b5e6-96231b3b80d8
the global TheJIT and TheJITResolver variables. Lazy compilation is supported
by a global map from a stub address to the JITResolver that knows how to
compile it.
Patch by Olivier Meurant!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95837 91177308-0d34-0410-b5e6-96231b3b80d8
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().
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95390 91177308-0d34-0410-b5e6-96231b3b80d8
1-argument ExecutionEngine::create(Module*) ambiguous with the signature that
used to be ExecutionEngine::create(ModuleProvider*, defaulted_params). Fixed
by removing the 1-argument create(). Fixes PR6221.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@95236 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94686 91177308-0d34-0410-b5e6-96231b3b80d8
1. MachineJumpTableInfo is now created lazily for a function the first time
it actually makes a jump table instead of for every function.
2. The encoding of jump table entries is now described by the
MachineJumpTableInfo::JTEntryKind enum. This enum is determined by the
TLI::getJumpTableEncoding() hook, instead of by lots of code scattered
throughout the compiler that "knows" that jump table entries are always
32-bits in pic mode (for example).
3. The size and alignment of jump table entries is now calculated based on
their kind, instead of at machinefunction creation time.
Future work includes using the EntryKind in more places in the compiler,
eliminating other logic that "knows" the layout of jump tables in various
situations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94470 91177308-0d34-0410-b5e6-96231b3b80d8
DebugLocTuple. Also use an AssertingVH to ensure that MDNodes aren't
destroyed while the FilenameCache is using them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94245 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@94164 91177308-0d34-0410-b5e6-96231b3b80d8
they're available_externally broke VMKit, which was relying on the fact that
functions would only be materialized when they were first called. We'll have
to wait for http://llvm.org/PR5737 to really fix this.
I also added a test for one of the F->isDeclaration() calls which wasn't
covered by anything else in the test suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91943 91177308-0d34-0410-b5e6-96231b3b80d8
argument to runJITOnFunction(), which caused a null pointer dereference at
every call.
Patch by Gianluca Guida!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91939 91177308-0d34-0410-b5e6-96231b3b80d8
remove start/finishGVStub and the BufferState helper class from the
MachineCodeEmitter interface. It has the side-effect of not setting the
indirect global writable and then executable on ARM, but that shouldn't be
necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91464 91177308-0d34-0410-b5e6-96231b3b80d8
isPodLike type trait. This is a generally useful type trait for
more than just DenseMap, and we really care about whether something
acts like a pod, not whether it really is a pod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91421 91177308-0d34-0410-b5e6-96231b3b80d8
nlewycky's fix to add -rdynamic so the JIT can look symbols up in Linux builds
of the JITTests binary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91250 91177308-0d34-0410-b5e6-96231b3b80d8
This code was crashing always with oprofile enabled, since it tried to create a StringRef
out of NULL, which run strlen on NULL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@91046 91177308-0d34-0410-b5e6-96231b3b80d8
way for each TargetJITInfo subclass to allocate its own stubs. This
means stubs aren't as exactly-sized anymore, but it lets us get rid of
TargetJITInfo::emitFunctionStubAtAddr(), which lets ARM and PPC
support the eager JIT, fixing http://llvm.org/PR4816.
* Rename the JITEmitter's stub creation functions to describe the kind
of stub they create. So far, all of them create lazy-compilation
stubs, but they sometimes get used when far-call stubs are needed.
Fixing http://llvm.org/PR5201 will involve fixing this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89715 91177308-0d34-0410-b5e6-96231b3b80d8
It's probably better in the long run to replace the
indirect-GlobalVariable system. That'll be done after a subsequent
patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89708 91177308-0d34-0410-b5e6-96231b3b80d8
libffi support and that the interpreter can't call external functions without
it. Patch by Timo Juhani Lindfors! Fixes PR5466.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@89062 91177308-0d34-0410-b5e6-96231b3b80d8
The large code model is documented at
http://www.x86-64.org/documentation/abi.pdf and says that calls should
assume their target doesn't live within the 32-bit pc-relative offset
that fits in the call instruction.
To do this, we turn off the global-address->target-global-address
conversion in X86TargetLowering::LowerCall(). The first attempt at
this broke the lazy JIT because it can separate the movabs(imm->reg)
from the actual call instruction. The lazy JIT receives the address of
the movabs as a relocation and needs to record the return address from
the call; and then when that call happens, it needs to patch the
movabs with the newly-compiled target. We could thread the call
instruction into the relocation and record the movabs<->call mapping
explicitly, but that seems to require at least as much new
complication in the code generator as this change.
To fix this, we make lazy functions _always_ go through a call
stub. You'd think we'd only have to force lazy calls through a stub on
difficult platforms, but that turns out to break indirect calls
through a function pointer. The right fix for that is to distinguish
between calls and address-of operations on uncompiled functions, but
that's complex enough to leave for someone else to do.
Another attempt at this defined a new CALL64i pseudo-instruction,
which expanded to a 2-instruction sequence in the assembly output and
was special-cased in the X86CodeEmitter's emitInstruction()
function. That broke indirect calls in the same way as above.
This patch also removes a hack forcing Darwin to the small code model.
Without far-call-stubs, the small code model requires things of the
JITMemoryManager that the DefaultJITMemoryManager can't provide.
Thanks to echristo for lots of testing!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@88984 91177308-0d34-0410-b5e6-96231b3b80d8
MachineRelocations, "stub" always refers to a far-call stub or a
load-a-faraway-global stub, so this patch adds "Far" to the term. (Other stubs
are used for lazy compilation and dlsym address replacement.) The variable was
also inconsistent between the positive and negative sense, and the positive
sense ("NeedStub") was more demanding than is accurate (since a nearby-enough
function can be called directly even if the platform often requires a stub).
Since the negative sense causes double-negatives, I switched to
"MayNeedFarStub" globally.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86363 91177308-0d34-0410-b5e6-96231b3b80d8
of going through the global TheJIT variable. This makes it easier to use
features of JITEmitter that aren't in JITCodeEmitter for fixing PR5201.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@86305 91177308-0d34-0410-b5e6-96231b3b80d8
now correctly runs clang's test/CodeGen/indirect-goto.c. The JIT will abort
on it until someone feels compelled to implement this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85488 91177308-0d34-0410-b5e6-96231b3b80d8
being destroyed. This allows users to run global optimizations like globaldce
even after some functions have been jitted.
This patch also removes the Function* parameter to
JITEventListener::NotifyFreeingMachineCode() since it can cause that to be
called when the Function is partially destroyed. This change will be even more
helpful later when I think we'll want to allow machine code to actually outlive
its Function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85182 91177308-0d34-0410-b5e6-96231b3b80d8
Remove LowerAllocations pass.
Update some more passes to treate free calls just like they were treating FreeInst.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@85176 91177308-0d34-0410-b5e6-96231b3b80d8
compiled.
When functions are compiled, they accumulate references in the JITResolver's
stub maps. This patch removes those references when the functions are
destroyed. It's illegal to destroy a Function when any thread may still try to
call its machine code.
This patch also updates r83987 to use ValueMap instead of explicit CallbackVHs
and fixes a couple "do stuff inside assert()" bugs from r84522.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84975 91177308-0d34-0410-b5e6-96231b3b80d8
JITEmitter.
I'm gradually making Functions auto-remove themselves from the JIT when they're
destroyed. In this case, the Function needs to be removed from the JITEmitter,
but the map recording which Functions need to be removed lived behind the
JITMemoryManager interface, which made things difficult.
This patch replaces the deallocateMemForFunction(Function*) method with a pair
of methods deallocateFunctionBody(void *) and deallocateExceptionTable(void *)
corresponding to the two startFoo/endFoo pairs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84651 91177308-0d34-0410-b5e6-96231b3b80d8
The JITResolver maps Functions to their canonical stubs and all callsites for
lazily-compiled functions to their target Functions. To make Function
destruction work, I'm going to need to remove all callsites on destruction, so
this patch also adds the reverse mapping for that.
There was an incorrect assumption in here that the only stub for a function
would be the one caused by needing to lazily compile it, while x86-64 far calls
and dlsym-stubs could also cause such stubs, but I didn't look for a test case
that the assumption broke.
This also adds DenseMapInfo<AssertingVH> so I can use DenseMaps instead of
std::maps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84522 91177308-0d34-0410-b5e6-96231b3b80d8
GlobalValue is destroyed. Function destruction still leaks machine code and
can crash on leaked stubs, but this is some progress.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83987 91177308-0d34-0410-b5e6-96231b3b80d8
mappings, which could cause errors and assert-failures. This patch fixes that,
adds a test, and refactors the global-mapping-removal code into a single place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83678 91177308-0d34-0410-b5e6-96231b3b80d8
the new predicates I added) instead of going through a context and doing a
pointer comparison. Besides being cheaper, this allows a smart compiler
to turn the if sequence into a switch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83297 91177308-0d34-0410-b5e6-96231b3b80d8
By the way, this code is buggy. You can't keep a map<MDNode *, something>
because the MDNode may be destroyed and reused for something else.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@83141 91177308-0d34-0410-b5e6-96231b3b80d8
feature, either build the JIT in debug mode to enable it by default or pass
-jit-emit-debug to lli.
Right now, the only debug information that this communicates to GDB is call
frame information, since it's already being generated to support exceptions in
the JIT. Eventually, when DWARF generation isn't tied so tightly to AsmPrinter,
it will be easy to push that information to GDB through this interface.
Here's a step-by-step breakdown of how the feature works:
- The JIT generates the machine code and DWARF call frame info
(.eh_frame/.debug_frame) for a function into memory.
- The JIT copies that info into an in-memory ELF file with a symbol for the
function.
- The JIT creates a code entry pointing to the ELF buffer and adds it to a
linked list hanging off of a global descriptor at a special symbol that GDB
knows about.
- The JIT calls a function marked noinline that GDB knows about and has put an
internal breakpoint in.
- GDB catches the breakpoint and reads the global descriptor to look for new
code.
- When sees there is new code, it reads the ELF from the inferior's memory and
adds it to itself as an object file.
- The JIT continues, and the next time we stop the program, we are able to
produce a proper backtrace.
Consider running the following program through the JIT:
#include <stdio.h>
void baz(short z) {
long w = z + 1;
printf("%d, %x\n", w, *((int*)NULL)); // SEGFAULT here
}
void bar(short y) {
int z = y + 1;
baz(z);
}
void foo(char x) {
short y = x + 1;
bar(y);
}
int main(int argc, char** argv) {
char x = 1;
foo(x);
}
Here is a backtrace before this patch:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaaabdfbd10 (LWP 25476)]
0x00002aaaabe7d1a8 in ?? ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in ?? ()
#1 0x0000000000000003 in ?? ()
#2 0x0000000000000004 in ?? ()
#3 0x00032aaaabe7cfd0 in ?? ()
#4 0x00002aaaabe7d12c in ?? ()
#5 0x00022aaa00000003 in ?? ()
#6 0x00002aaaabe7d0aa in ?? ()
#7 0x01000002abe7cff0 in ?? ()
#8 0x00002aaaabe7d02c in ?? ()
#9 0x0100000000000001 in ?? ()
#10 0x00000000014388e0 in ?? ()
#11 0x00007fff00000001 in ?? ()
#12 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=@0x7fffffffe050)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#13 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=@0x13f06f8, envp=0x7fffffffe3b0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#14 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe398,
envp=0x7fffffffe3b0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
And a backtrace after this patch:
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabe7d1a8 in baz ()
(gdb) bt
#0 0x00002aaaabe7d1a8 in baz ()
#1 0x00002aaaabe7d12c in bar ()
#2 0x00002aaaabe7d0aa in foo ()
#3 0x00002aaaabe7d02c in main ()
#4 0x0000000000b870a2 in llvm::JIT::runFunction (this=0x1405b70,
F=0x14024e0, ArgValues=...)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/JIT/JIT.cpp:395
#5 0x0000000000baa4c5 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1405b70, Fn=0x14024e0, argv=..., envp=0x7fffffffe3c0)
at /home/rnk/llvm-gdb/lib/ExecutionEngine/ExecutionEngine.cpp:377
#6 0x00000000007ebd52 in main (argc=2, argv=0x7fffffffe3a8,
envp=0x7fffffffe3c0) at /home/rnk/llvm-gdb/tools/lli/lli.cpp:208
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82418 91177308-0d34-0410-b5e6-96231b3b80d8
desired triplet is a sub-target, e.g. thumbv7 vs. arm host). Reverting the
patch isn't quite right either since the previous behavior does not allow the
triplet to be overridden with -march.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80742 91177308-0d34-0410-b5e6-96231b3b80d8
members that call methods that read the PoisonMemory member.
This fixes potential spurious (though probably otherwise
harmless) poising of unused memory, and fixes the
associated valgrind error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80192 91177308-0d34-0410-b5e6-96231b3b80d8
really old code from when we were running sparcv9 bc files on x86
(before I ported llvm-gcc 3 to work on x86) :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79871 91177308-0d34-0410-b5e6-96231b3b80d8
bytes. libgcc doesn't seem to mind, but if you pass this DWARF to GDB, it
doesn't like it.
Also make the JIT memory manager to initialize it's memory to garbage in debug
mode, so that it's easier to find bugs like these in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79674 91177308-0d34-0410-b5e6-96231b3b80d8
and short. Well, it's kinda short. Definitely nasty and brutish.
The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.
Built on Darwin and verified no llvm-core "make check" regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78625 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.
This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78400 91177308-0d34-0410-b5e6-96231b3b80d8
This is not just a matter of passing in the target triple from the module;
currently backends are making decisions based on the build and host
architecture. The goal is to migrate to making these decisions based off of the
triple (in conjunction with the feature string). Thus most clients pass in the
target triple, or the host triple if that is empty.
This has one important change in the way behavior of the JIT and llc.
For the JIT, it was previously selecting the Target based on the host
(naturally), but it was setting the target machine features based on the triple
from the module. Now it is setting the target machine features based on the
triple of the host.
For LLC, -march was previously only used to select the target, the target
machine features were initialized from the module's triple (which may have been
empty). Now the target triple is taken from the module, or the host's triple is
used if that is empty. Then the triple is adjusted to match -march.
The take away is that -march for llc is now used in conjunction with the host
triple to initialize the subtarget. If users want more deterministic behavior
from llc, they should use -mtriple, or set the triple in the input module.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77946 91177308-0d34-0410-b5e6-96231b3b80d8
there is no new block added to the free list. Therefore on the next
startFunctionBody call, a new slab must be allocated.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77520 91177308-0d34-0410-b5e6-96231b3b80d8
- Instead of requiring targets to define a JIT quality match function, we just
have them specify if they support a JIT.
- Target selection for the JIT just gets the host triple and looks for the best
target which matches the triple and has a JIT.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77060 91177308-0d34-0410-b5e6-96231b3b80d8
- Some clients which used DOUT have moved to DEBUG. We are deprecating the
"magic" DOUT behavior which avoided calling printing functions when the
statement was disabled. In addition to being unnecessary magic, it had the
downside of leaving code in -Asserts builds, and of hiding potentially
unnecessary computations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77019 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76828 91177308-0d34-0410-b5e6-96231b3b80d8
call to the MachineCodeEmitter interface and made copying the start
line of a function not conditional on whether we're emitting Dwarf
debug information. I'll propagate the processDebugLoc() calls to the
non-X86 targets in a followup patch.
In the long run, it'll probably be better to gather this information
through the DwarfWriter, but the DwarfWriter currently depends on the
AsmPrinter and TargetAsmInfo, and fixing that would be out of the way
for this patch.
There's a bug in OProfile 0.9.4 that makes it ignore line numbers for
addresses above 4G, and a patch fixing it at
http://thread.gmane.org/gmane.linux.oprofile/7634
Sample output:
$ sudo opcontrol --reset; sudo opcontrol --start-daemon; sudo opcontrol --start; `pwd`/Debug/bin/lli fib.bc; sudo opcontrol --stop
Signalling daemon... done
Profiler running.
fib(40) == 165580141
Stopping profiling.
$ opreport -g -d -l `pwd`/Debug/bin/lli|head -60
Overflow stats not available
CPU: Core 2, speed 1998 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
vma samples % linenr info image name symbol name
00007f67a30370b0 25489 61.2554 fib.c:24 10946.jo fib_left
00007f67a30370b0 1634 6.4106 fib.c:24
00007f67a30370b1 83 0.3256 fib.c:24
00007f67a30370b9 1997 7.8348 fib.c:24
00007f67a30370c6 2080 8.1604 fib.c:27
00007f67a30370c8 988 3.8762 fib.c:27
00007f67a30370cd 1315 5.1591 fib.c:27
00007f67a30370cf 251 0.9847 fib.c:27
00007f67a30370d3 1191 4.6726 fib.c:27
00007f67a30370d6 975 3.8252 fib.c:27
00007f67a30370db 1010 3.9625 fib.c:27
00007f67a30370dd 242 0.9494 fib.c:27
00007f67a30370e1 2782 10.9145 fib.c:28
00007f67a30370e5 3768 14.7828 fib.c:28
00007f67a30370eb 615 2.4128 (no location information)
00007f67a30370f3 6558 25.7287 (no location information)
00007f67a3037100 15603 37.4973 fib.c:29 10946.jo fib_right
00007f67a3037100 1646 10.5493 fib.c:29
00007f67a3037101 45 0.2884 fib.c:29
00007f67a3037109 2372 15.2022 fib.c:29
00007f67a3037116 2234 14.3178 fib.c:32
00007f67a3037118 612 3.9223 fib.c:32
00007f67a303711d 622 3.9864 fib.c:32
00007f67a303711f 385 2.4675 fib.c:32
00007f67a3037123 404 2.5892 fib.c:32
00007f67a3037126 634 4.0633 fib.c:32
00007f67a303712b 870 5.5759 fib.c:32
00007f67a303712d 62 0.3974 fib.c:32
00007f67a3037131 1848 11.8439 fib.c:33
00007f67a3037135 2840 18.2016 fib.c:33
00007f67a303713a 1 0.0064 fib.c:33
00007f67a303713b 1023 6.5564 (no location information)
00007f67a3037143 5 0.0320 (no location information)
000000000080c1e4 15 0.0360 MachineOperand.h:150 lli llvm::MachineOperand::isReg() const
000000000080c1e4 6 40.0000 MachineOperand.h:150
000000000080c1ec 2 13.3333 MachineOperand.h:150
...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76102 91177308-0d34-0410-b5e6-96231b3b80d8
--- Reverse-merging r75799 into '.':
U test/Analysis/PointerTracking
U include/llvm/Target/TargetMachineRegistry.h
U include/llvm/Target/TargetMachine.h
U include/llvm/Target/TargetRegistry.h
U include/llvm/Target/TargetSelect.h
U tools/lto/LTOCodeGenerator.cpp
U tools/lto/LTOModule.cpp
U tools/llc/llc.cpp
U lib/Target/PowerPC/PPCTargetMachine.h
U lib/Target/PowerPC/AsmPrinter/PPCAsmPrinter.cpp
U lib/Target/PowerPC/PPCTargetMachine.cpp
U lib/Target/PowerPC/PPC.h
U lib/Target/ARM/ARMTargetMachine.cpp
U lib/Target/ARM/AsmPrinter/ARMAsmPrinter.cpp
U lib/Target/ARM/ARMTargetMachine.h
U lib/Target/ARM/ARM.h
U lib/Target/XCore/XCoreTargetMachine.cpp
U lib/Target/XCore/XCoreTargetMachine.h
U lib/Target/PIC16/PIC16TargetMachine.cpp
U lib/Target/PIC16/PIC16TargetMachine.h
U lib/Target/Alpha/AsmPrinter/AlphaAsmPrinter.cpp
U lib/Target/Alpha/AlphaTargetMachine.cpp
U lib/Target/Alpha/AlphaTargetMachine.h
U lib/Target/X86/X86TargetMachine.h
U lib/Target/X86/X86.h
U lib/Target/X86/AsmPrinter/X86ATTAsmPrinter.h
U lib/Target/X86/AsmPrinter/X86AsmPrinter.cpp
U lib/Target/X86/AsmPrinter/X86IntelAsmPrinter.h
U lib/Target/X86/X86TargetMachine.cpp
U lib/Target/MSP430/MSP430TargetMachine.cpp
U lib/Target/MSP430/MSP430TargetMachine.h
U lib/Target/CppBackend/CPPTargetMachine.h
U lib/Target/CppBackend/CPPBackend.cpp
U lib/Target/CBackend/CTargetMachine.h
U lib/Target/CBackend/CBackend.cpp
U lib/Target/TargetMachine.cpp
U lib/Target/IA64/IA64TargetMachine.cpp
U lib/Target/IA64/AsmPrinter/IA64AsmPrinter.cpp
U lib/Target/IA64/IA64TargetMachine.h
U lib/Target/IA64/IA64.h
U lib/Target/MSIL/MSILWriter.cpp
U lib/Target/CellSPU/SPUTargetMachine.h
U lib/Target/CellSPU/SPU.h
U lib/Target/CellSPU/AsmPrinter/SPUAsmPrinter.cpp
U lib/Target/CellSPU/SPUTargetMachine.cpp
U lib/Target/Mips/AsmPrinter/MipsAsmPrinter.cpp
U lib/Target/Mips/MipsTargetMachine.cpp
U lib/Target/Mips/MipsTargetMachine.h
U lib/Target/Mips/Mips.h
U lib/Target/Sparc/AsmPrinter/SparcAsmPrinter.cpp
U lib/Target/Sparc/SparcTargetMachine.cpp
U lib/Target/Sparc/SparcTargetMachine.h
U lib/ExecutionEngine/JIT/TargetSelect.cpp
U lib/Support/TargetRegistry.cpp
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75820 91177308-0d34-0410-b5e6-96231b3b80d8
- They still use the TargetMachineRegistry to populate the contents of the
-march option (via the listener interface). We can't just populate it in the
option parser because we can't expect the TargetRegistry to be populated yet
(we no longer rely on static constructors).
- There are a couple ways to finish killing off TargetMachineRegistry, but I
haven't figured out the cleanest one yet...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75773 91177308-0d34-0410-b5e6-96231b3b80d8
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75640 91177308-0d34-0410-b5e6-96231b3b80d8
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75379 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75279 91177308-0d34-0410-b5e6-96231b3b80d8
default, this option is not enabled to support clients who rely on
this behavior.
Fixes http://llvm.org/PR4483
A patch to allocate additional memory for globals after we run out is
forthcoming.
Patch by Reid Kleckner!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@75059 91177308-0d34-0410-b5e6-96231b3b80d8
This will replace exit()/abort() style error handling with an API
that allows clients to register custom error handling hooks.
The default is to call exit(1) when no error handler is provided.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74922 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74157 91177308-0d34-0410-b5e6-96231b3b80d8
libraries instead of relinked objects, the interpreter, JIT, and native
target libraries were not being linked in to an ocaml program using the
ExecutionEngine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74117 91177308-0d34-0410-b5e6-96231b3b80d8
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72897 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a new class (MachineCodeInfo) that the JIT can fill in with details. Right now, just the address and the size of the machine code are reported.
Patch by Evan Phoenix!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72040 91177308-0d34-0410-b5e6-96231b3b80d8
an optimization level instead of a simple boolean telling it to generate code
"fast" or the other type of "fast".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70347 91177308-0d34-0410-b5e6-96231b3b80d8
another stub, but then never calling the jitted function) can cause the JIT to
leave a stub in place. Judging by the comments this is a known deficiency, so
we're just not going to use AssertingVH for the StubToFunctionTy map.
Also shorten some lines longer than 80 columns.
This fixes the "make check" failure with ocaml on x86-64 linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@70185 91177308-0d34-0410-b5e6-96231b3b80d8
locks must be matched with unlocks. Also, use calloc to allocate the
block so that it is properly zero'd. Thanks to Nick Kledzik for
tracking this down.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@69314 91177308-0d34-0410-b5e6-96231b3b80d8
is appropriate. This helps visually differentiate host-oriented
calculations from target-oriented calculations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@68227 91177308-0d34-0410-b5e6-96231b3b80d8
1. ConstantPoolSDNode alignment field is log2 value of the alignment requirement. This is not consistent with other SDNode variants.
2. MachineConstantPool alignment field is also a log2 value.
3. However, some places are creating ConstantPoolSDNode with alignment value rather than log2 values. This creates entries with artificially large alignments, e.g. 256 for SSE vector values.
4. Constant pool entry offsets are computed when they are created. However, asm printer group them by sections. That means the offsets are no longer valid. However, asm printer uses them to determine size of padding between entries.
5. Asm printer uses expensive data structure multimap to track constant pool entries by sections.
6. Asm printer iterate over SmallPtrSet when it's emitting constant pool entries. This is non-deterministic.
Solutions:
1. ConstantPoolSDNode alignment field is changed to keep non-log2 value.
2. MachineConstantPool alignment field is also changed to keep non-log2 value.
3. Functions that create ConstantPool nodes are passing in non-log2 alignments.
4. MachineConstantPoolEntry no longer keeps an offset field. It's replaced with an alignment field. Offsets are not computed when constant pool entries are created. They are computed on the fly in asm printer and JIT.
5. Asm printer uses cheaper data structure to group constant pool entries.
6. Asm printer compute entry offsets after grouping is done.
7. Change JIT code to compute entry offsets on the fly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66875 91177308-0d34-0410-b5e6-96231b3b80d8
allocating memory in the JIT. This is insanely inefficient, but
hey, most people implement their own memory managers anyway.
Patch by Eric Yew!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66472 91177308-0d34-0410-b5e6-96231b3b80d8
and extern_weak_odr. These are the same as the non-odr versions,
except that they indicate that the global will only be overridden
by an *equivalent* global. In C, a function with weak linkage can
be overridden by a function which behaves completely differently.
This means that IP passes have to skip weak functions, since any
deductions made from the function definition might be wrong, since
the definition could be replaced by something completely different
at link time. This is not allowed in C++, thanks to the ODR
(One-Definition-Rule): if a function is replaced by another at
link-time, then the new function must be the same as the original
function. If a language knows that a function or other global can
only be overridden by an equivalent global, it can give it the
weak_odr linkage type, and the optimizers will understand that it
is alright to make deductions based on the function body. The
code generators on the other hand map weak and weak_odr linkage
to the same thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66339 91177308-0d34-0410-b5e6-96231b3b80d8
1. When the JIT is asked to remove a function, updating it's
mapping to 0, we invalidate any function stubs used only
by that function. Now, also invalidate the JIT's mapping
from the GV the stub pointed to, to the address of the GV.
2. When dlsym stubs for cross-process JIT are enabled, do not
abort just because a named function cannot be found in the
JIT's process.
3. Fix various assumptions about when it is ok to use the lazy
resolver when non-lazy JITing is enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66324 91177308-0d34-0410-b5e6-96231b3b80d8
This invalidates the stubs in the resolver map when they are no longer referenced,
and should the JIT memory manager ever pick up a deallocateStub interface, the
JIT could reclaim the memory for unused stubs as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66141 91177308-0d34-0410-b5e6-96231b3b80d8
on failure to resolve it.
Do not abort on failure to resolve an external symbol when using dlsym stubs,
since the symbol may not be in the JIT's address space. Just use 0.
Allow dlsym stubs to differentiate between GlobalVars and Functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@66050 91177308-0d34-0410-b5e6-96231b3b80d8
