| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 222945
|
|
|
|
| |
llvm-svn: 222840
|
|
|
|
|
|
| |
http://bb.pgr.jp/builders/ninja-clang-i686-msc17-R/builds/11753
llvm-svn: 222833
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when loading an object file, RuntimeDyld (1) took ownership of the
ObjectFile instance (and associated MemoryBuffer), (2) potentially modified the
object in-place, and (3) returned an ObjectImage that managed ownership of the
now-modified object and provided some convenience methods. This scheme accreted
over several years as features were tacked on to RuntimeDyld, and was both
unintuitive and unsafe (See e.g. http://llvm.org/PR20722).
This patch fixes the issue by removing all ownership and in-place modification
of object files from RuntimeDyld. Existing behavior, including debugger
registration, is preserved.
Noteworthy changes include:
(1) ObjectFile instances are now passed to RuntimeDyld by const-ref.
(2) The ObjectImage and ObjectBuffer classes have been removed entirely, they
existed to model ownership within RuntimeDyld, and so are no longer needed.
(3) RuntimeDyld::loadObject now returns an instance of a new class,
RuntimeDyld::LoadedObjectInfo, which can be used to construct a modified
object suitable for registration with the debugger, following the existing
debugger registration scheme.
(4) The JITRegistrar class has been removed, and the GDBRegistrar class has been
re-written as a JITEventListener.
This should fix http://llvm.org/PR20722 .
llvm-svn: 222810
|
|
|
|
| |
llvm-svn: 218318
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the old JIT memory manager (which does not provide any
useful functionality now that the old JIT is gone), and migrates the few
remaining clients over to SectionMemoryManager.
http://llvm.org/PR20848
llvm-svn: 218316
|
|
|
|
|
|
|
|
| |
Approved by Jim Grosbach, Lang Hames, Rafael Espindola.
This reinstates commits r215111, 215115, 215116, 215117, 215136.
llvm-svn: 216982
|
|
|
|
| |
llvm-svn: 216583
|
|
|
|
|
|
|
| |
Long term the idea if for the engine to not own the buffers, but for now
this is consistent with the rest of the API.
llvm-svn: 216484
|
|
|
|
| |
llvm-svn: 216466
|
|
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|
|
|
|
| |
llvm-svn: 216071
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
class.
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
|