llvm-svn: 215566

Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)

Changes made by clang-tidy with minor tweaks.

llvm-svn: 215558

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

llvm-svn: 215116

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: 212920

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: 207394

llvm-svn: 207176

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

llvm-svn: 206848

behavior based on other files defining DEBUG_TYPE, which means it cannot
define DEBUG_TYPE at all. This is actually better IMO as it forces folks
to define relevant DEBUG_TYPEs for their files. However, it requires all
files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't
already. I've updated all such files in LLVM and will do the same for
other upstream projects.

This still leaves one important change in how LLVM uses the DEBUG_TYPE
macro going forward: we need to only define the macro *after* header
files have been #include-ed. Previously, this wasn't possible because
Debug.h required the macro to be pre-defined. This commit removes that.
By defining DEBUG_TYPE after the includes two things are fixed:

- Header files that need to provide a DEBUG_TYPE for some inline code
  can do so by defining the macro before their inline code and undef-ing
  it afterward so the macro does not escape.

- We no longer have rampant ODR violations due to including headers with
  different DEBUG_TYPE definitions. This may be mostly an academic
  violation today, but with modules these types of violations are easy
  to check for and potentially very relevant.

Where necessary to suppor headers with DEBUG_TYPE, I have moved the
definitions below the includes in this commit. I plan to move the rest
of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big
enough.

The comments in Debug.h, which were hilariously out of date already,
have been updated to reflect the recommended practice going forward.

llvm-svn: 206822

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

llvm-svn: 202811

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

llvm-svn: 200297

Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.

llvm-svn: 200018

This enables IO error reports in both the child and server processes.

The scheme still isn't entirely satisfactory and output is jumbled but it beats
having no output at all. This will hopefully unblock ARM support (PR18057).

llvm-svn: 200017

The client and server now use a single unified low-level RPC core built around
LLVM's existing cross-platform abstractions.

llvm-svn: 199947

llvm-svn: 199930

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

llvm-svn: 199889

Looks like some parts still need detangling. Let's see if this holds for now.

llvm-svn: 199885

llvm-svn: 199882

Eliminate the copies LLVM's System mmap and cache invalidation code. These were
slowly drifting away from the original version, and moreover the copied code
was a dead end in terms of portability.

We now statically link to Support but in practice with stripping this adds next
to no weight to the resultant binary.

Also avoid installing lli-child-target to the user's $PATH. It's not meant to
be run directly.

llvm-svn: 199881

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

llvm-svn: 199268

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: 199080