inconsistent with autoconf, which by default set BINUTILS_INCDIR to
empty and exclude gold from target list.

Based on a patch by Haitao Li!

llvm-svn: 131229

llvm-svn: 131187

This change allows bugpoint to pinpoint the "opt" pass and bitcode
segment responsible for a crash caused by miscompilation. At least it
works well for me now, without having to create any custom execution
wrappers.

llvm-svn: 131186

llvm-svn: 131094

llvm-svn: 130860

llvm-svn: 130712

for all symbol differences and can drop the old EmitPCRelSymbolValue
method.

This also make getExprForFDESymbol on ELF equal to the one on MachO, and it
can be made non-virtual.

llvm-svn: 130634

the final assembly. It is the same technique used when targeting
assemblers that don't support .loc.

llvm-svn: 130587

llvm-svn: 130393

llvm-svn: 130391

llvm-svn: 130090

llvm-svn: 130068

llvm-svn: 130021

llvm-svn: 129955

llvm-svn: 129902

llvm-svn: 129841

triple component.

llvm-svn: 129838

predicates.

llvm-svn: 129816

 - As before, there is a minor semantic change here (evidenced by the test
   change) for Darwin triples that have no version component. I debated changing
   the default behavior of isOSVersionLT, but decided it made more sense for
   triples to be explicit.

llvm-svn: 129805

Luis Felipe Strano Moraes!

llvm-svn: 129558

Relocations between the object modules are properly resolved, as in the
following trivial example:

$ cat t.c
int foo();
int main() {
    return foo();
}
$ cat foo.c
int foo() {
    return 65;
}
$ clang -c t.c -fno-asynchronous-unwind-tables
$ clang -c foo.c -fno-asynchronous-unwind-tables
$ llvm-rtdyld t.o foo.o ; echo $?
loaded '_main' at: 0x10015c000
65

llvm-svn: 129448

llvm-svn: 129446

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
$

llvm-svn: 129388

llvm-svn: 129328

llvm-svn: 129271

making the MC disassembler tester more robust.

llvm-svn: 129175

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.

llvm-svn: 129138

to map the file both in the linker and in the plugin.

llvm-svn: 129109

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.

llvm-svn: 128973

llvm-svn: 128938

developers can see if their driver changed any cl::Option's. The
current implementation isn't perfect but handles most kinds of
options. This is nice to have when decomposing the stages of
compilation and moving between different drivers. It's also a good
sanity check when comparing results produced by different command line
invocations that are expected to produce the comparable results.

Note: This is not an attempt to prolong the life of cl::Option. On the
contrary, it's a placeholder for a feature that must exist when
cl::Option is replaced by a more appropriate framework. A new
framework needs: a central option registry, dynamic name lookup,
non-global containers of option values (e.g. per-module,
per-function), *and* the ability to print options values and their defaults at
any point during compilation.

llvm-svn: 128910

llvm-svn: 128905

scheme is used by the functionality related to find_package.

llvm-svn: 128889

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.

llvm-svn: 128851

llvm-svn: 128839

llvm-svn: 128834

llvm-svn: 128831

separate executable.

llvm-svn: 128801

llvm-svn: 128740

with the contents of CMAKE_C(XX)_FLAGS too, else `llvm-config
--c(xx)flags' doesn't tell the absolute truth.

This comes from PR9603 and is based on a patch by Ryuta Suzuki!

llvm-svn: 128727