- Aug 27, 2014
-
-
Rafael Espindola authored
llvm-svn: 216583
-
- Aug 26, 2014
-
-
Rafael Espindola authored
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
-
Rafael Espindola authored
llvm-svn: 216466
-
- Aug 25, 2014
-
-
Rafael Espindola authored
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
-
- Aug 20, 2014
-
-
Rafael Espindola authored
llvm-svn: 216071
-
- Aug 19, 2014
-
-
Rafael Espindola authored
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
-
Rafael Espindola authored
llvm-svn: 215967
-
- Aug 13, 2014
-
-
Rafael Espindola authored
llvm-svn: 215566
-
Benjamin Kramer authored
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
-
- Aug 08, 2014
-
-
Eric Christopher authored
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
-
- Aug 07, 2014
-
-
Rafael Espindola authored
llvm-svn: 215116
-
Rafael Espindola authored
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
-
- Aug 01, 2014
-
-
Rafael Espindola authored
Also fix the error handling. No testcaes, issue found by inspection. Thanks to David Blaikie for the suggestion. llvm-svn: 214535
-
Rafael Espindola authored
llvm-svn: 214533
-
- Jul 31, 2014
-
-
Rafael Espindola authored
llvm-svn: 214377
-
- Jul 14, 2014
-
-
NAKAMURA Takumi authored
llvm-svn: 212920
-
- Jul 06, 2014
-
-
Rafael Espindola authored
llvm-svn: 212405
-
- Jun 24, 2014
-
-
Rafael Espindola authored
Once the objects are constructed, they own the buffer. Passing a unique_ptr makes that clear. llvm-svn: 211595
-
- Jun 13, 2014
-
-
Rafael Espindola authored
llvm-svn: 210876
-
- Jun 12, 2014
-
-
Rafael Espindola authored
This should make sure that most new uses use the std prefix. llvm-svn: 210835
-
- Apr 29, 2014
-
-
David Blaikie authored
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
-
- Apr 28, 2014
-
-
Craig Topper authored
llvm-svn: 207394
-
- Apr 25, 2014
-
-
Craig Topper authored
llvm-svn: 207176
-
- Apr 22, 2014
-
-
Chandler Carruth authored
definition below all of the header #include lines, tools edition. llvm-svn: 206848
-
Chandler Carruth authored
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
-
- Mar 08, 2014
-
-
Craig Topper authored
llvm-svn: 203345
-
- Mar 06, 2014
-
-
Ahmed Charles authored
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
-
- Mar 05, 2014
-
-
Ahmed Charles authored
llvm-svn: 202957
-
- Mar 04, 2014
-
-
Chandler Carruth authored
llvm-svn: 202811
-
- Feb 24, 2014
-
-
Rafael Espindola authored
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
-
- Jan 28, 2014
-
-
NAKAMURA Takumi authored
llvm-svn: 200297
-
- Jan 24, 2014
-
-
Alp Toker authored
Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
-
Alp Toker authored
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
-
- Jan 23, 2014
-
-
Alp Toker authored
The client and server now use a single unified low-level RPC core built around LLVM's existing cross-platform abstractions. llvm-svn: 199947
-
Alp Toker authored
llvm-svn: 199930
-
Alp Toker authored
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
-
NAKAMURA Takumi authored
llvm-svn: 199889
-
Alp Toker authored
Looks like some parts still need detangling. Let's see if this holds for now. llvm-svn: 199885
-
Alp Toker authored
llvm-svn: 199882
-
Alp Toker authored
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
-