| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
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
|
|
|
|
|
|
| |
constructor and destructor.
llvm-svn: 218154
|
|
|
|
| |
llvm-svn: 207083
|
|
|
|
|
|
|
|
| |
Ivan Puzyrevskiy.
Fixes PR15750. Thanks Jim and Ivan.
llvm-svn: 203853
|
|
|
|
|
|
| |
class.
llvm-svn: 203344
|
|
|
|
| |
llvm-svn: 199352
|
|
|
|
|
|
| |
Patch by Andrew MacPherson. I just tweaked the comment.
llvm-svn: 199350
|
|
|
|
|
|
| |
mangling prefix to this symbol.
llvm-svn: 171025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
|
|
|
|
| |
llvm-svn: 165053
|
|
llvm-svn: 154872
|