| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
llvm-ar is the only tool that needs to write archive files. Every other tool
should be able to use the lib/Object interface.
llvm-svn: 184083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
llvm-svn: 184019
|
|
|
|
|
|
|
|
|
|
| |
missed in the first pass because the script didn't yet handle include
guards.
Note that the script is now able to handle all of these headers without
manual edits. =]
llvm-svn: 169224
|
|
|
|
|
|
| |
ArchiveMemberHeader. Found by gcc48 -Wcast-qual.
llvm-svn: 163255
|
|
|
|
| |
llvm-svn: 120298
|
|
|
|
| |
llvm-svn: 101783
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.
Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.
Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.
llvm-svn: 94686
|
|
|
|
| |
llvm-svn: 78690
|
|
|
|
|
|
|
|
| |
header, to make LLVMContextImpl.h
not hideous. Also, fix some MSVC compile errors.
llvm-svn: 78115
|
|
|
|
|
|
|
|
| |
the last time, for the
moment, that I will need to make far-reaching changes.
llvm-svn: 74655
|
|
|
|
| |
llvm-svn: 74640
|
|
|
|
|
|
|
|
|
|
| |
LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.
Patches for Clang and LLVM-GCC to follow.
llvm-svn: 74614
|
|
|
|
|
|
| |
annoying warnings.
llvm-svn: 47367
|
|
|
|
| |
llvm-svn: 45418
|
|
|
|
|
|
| |
Almost all occurrences of "bytecode" in the sources have been eliminated.
llvm-svn: 37913
|
|
llvm-svn: 36886
|