Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries
(like Archive) and we had to create dummy buffers just to handle that. It is
also a bad fit for IRObjectFile where the Module wants to own the buffer too.

Keeping this ownership would make supporting IR inside native objects
particularly painful.

This patch focuses in lib/Object. If something elsewhere used to own an Binary,
now it also owns a MemoryBuffer.

This patch introduces a few new types.

* MemoryBufferRef. This is just a pair of StringRefs for the data and name.
  This is to MemoryBuffer as StringRef is to std::string.
* OwningBinary. A combination of Binary and a MemoryBuffer. This is needed
  for convenience functions that take a filename and return both the
  buffer and the Binary using that buffer.

The C api now uses OwningBinary to avoid any change in semantics. I will start
a new thread to see if we want to change it and how.

llvm-svn: 216002

llvm-svn: 215967

llvm-svn: 215566

be deleted. This will be reapplied as soon as possible and before
the 3.6 branch date at any rate.

Approved by Jim Grosbach, Lang Hames, Rafael Espindola.

This reverts commits r215111, 215115, 215116, 215117, 215136.

llvm-svn: 215154

I am sure we will be finding bits and pieces of dead code for years to
come, but this is a good start.

Thanks to Lang Hames for making MCJIT a good replacement!

llvm-svn: 215111

Also fix the error handling. No testcaes, issue found by inspection.

Thanks to David Blaikie for the suggestion.

llvm-svn: 214535

llvm-svn: 214533

llvm-svn: 214377

llvm-svn: 212405

Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.

llvm-svn: 211595

llvm-svn: 210876

This should make sure that most new uses use the std prefix.

llvm-svn: 210835

This starts in MCJIT::getSymbolAddress where the
unique_ptr<object::Binary> is release()d and (after a cast) passed to a
single caller, MCJIT::addObjectFile.

addObjectFile calls RuntimeDyld::loadObject.
RuntimeDld::loadObject calls RuntimeDyldELF::createObjectFromFile

And the pointer is never owned at this point. I say this point, because
the alternative codepath, RuntimeDyldMachO::createObjectFile certainly
does take ownership, so this seemed like a good hint that this was a/the
right place to take ownership.

llvm-svn: 207580

llvm-svn: 207176

definition below all of the header #include lines, tools edition.

llvm-svn: 206848

llvm-svn: 203345

This compiles with no changes to clang/lld/lldb with MSVC and includes
overloads to various functions which are used by those projects and llvm
which have OwningPtr's as parameters. This should allow out of tree
projects some time to move. There are also no changes to libs/Target,
which should help out of tree targets have time to move, if necessary.

llvm-svn: 203083

llvm-svn: 202957

After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)

llvm-svn: 202052

Eliminates the LLI_BUILDING_CHILD build hack from r199885.

Also add a FIXME to remove code that tricks the tests into passing when the
feature fails to work. Please don't do stuff like this, the tests exist for a
reason!

llvm-svn: 199929

The execution code path crashes if it can't execute the binary so we might as
well take precautions here.

llvm-svn: 199844

llvm-svn: 199835

llvm-svn: 199776

llvm-svn: 199275

MCJIT remote execution (ChildTarget+RemoteTargetExternal) protocol was in
dire need of refactoring. It was fail-prone, had no error reporting and
implemented the same message logic on every single function.

This patch rectifies it, and makes it work on ARM, where it was randomly
failing. Other architectures shall profit from this change as well, making
their buildbots and releases more reliable.

llvm-svn: 199261

llvm-svn: 198929

llvm-svn: 198928

llvm-svn: 198927

new in C++11.

llvm-svn: 198853

root path to which object files managed by the LLIObjectCache instance should be
written. This option defaults to "", in which case objects are cached in the
same directory as the bitcode they are derived from.

The load-object-a.ll test has been rewritten to use this option to support
testing in environments where the test directory is not writable.

llvm-svn: 198852

llvm-svn: 198821

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

llvm-svn: 196654

llvm-svn: 196641

Patch by Andy Kaylor, with minor edits to resolve merge conflicts.

llvm-svn: 196639

llvm-svn: 193571

llvm-svn: 193570

llvm-svn: 193552

llvm-svn: 193544

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