| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
I think it is clear by now that the new linker is viable.
llvm-svn: 262158
|
|
|
|
|
|
| |
This just reduces the noise from another patch.
llvm-svn: 235933
|
|
|
|
|
|
| |
This just reduces the noise from another patch.
llvm-svn: 235776
|
|
|
|
| |
llvm-svn: 235741
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loadFile could load mulitple files just because yaml has a feature for
putting multiple documents in one file.
Designing a linker around what yaml can do seems like a bad idea to
me. This patch changes it to read a single file.
There are further improvements to be done to the api and they
will follow shortly.
llvm-svn: 235724
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, ELFReader takes three template arguments: EFLT,
LinkingContextT and FileT. FileT is itself templated.
So it was a bit complicated. Maybe too much.
Most architectures don't actually need to be parameterized for ELFT.
For example, x86 is always ELF32LE and x86-64 is ELF64LE.
However, because ELFReader requires a ELFT argument, we needed
to parameterize a class even if not needed.
This patch removes the parameter from the class. So now we can
de-templatize such classes (I didn't do that in this patch, though).
This patch also removes ContextT parameter since it didn't have to be
passed as a template argument.
llvm-svn: 234853
|
|
|
|
| |
llvm-svn: 234823
|
|
|
|
| |
llvm-svn: 234791
|
|
|
|
|
|
|
| |
Having std:move(mb) and mb->getBuffer() in the same argument list is not safe
because the order of evaluation is not defined.
llvm-svn: 234541
|
|
|
|
|
|
|
|
| |
CreateELF.h was included only by ELFReader.h, and it was used only
by ELFReader class. By making the function a member of the class,
we can remove template parameters.
llvm-svn: 234540
|
|
|
|
|
|
|
|
| |
canParse took three parameters -- file magic, filename extension and
memory buffer. All but YAMLReader ignored the second parameter.
This patch removes the parameter.
llvm-svn: 234080
|
|
|
|
| |
llvm-svn: 234077
|
|
|
|
|
|
|
|
|
|
| |
Because of the previous change (r234074), ELFObjectReader became just
an alias for ELFReader. We can replace all occurrences of ELFObjectReader
with ELFReader.
In this patch, I also replaced ELFDSOReader to remove the alias template.
llvm-svn: 234076
|
|
|
|
|
|
|
|
| |
So that we can remove one template parameter from ELFReader.
ELF port is heavily templatized, and I want to reduce the usage
where possible.
llvm-svn: 234074
|
|
|
|
|
|
|
|
|
|
| |
Only MIPS defined the member function, but this feature is not actually
MIPS-specific. Also, the dependency to the MIPS-only member function
prevented us from merging <Arch>ELF{Object,DSO}Reader classes.
This patch moves the feature from MipsLinkingContext to LinkingContext.
llvm-svn: 234068
|
|
|
|
|
|
|
| |
The two classes are the same other than a few exceptions.
This patch merges them using templates.
llvm-svn: 234060
|
|
|
|
|
|
|
|
| |
All <Arch>ELFFileCreateFileTraits structs are the same except its file type.
That means that we don't need to pass the type traits. Instead, we can only
pass file types. By doing this, we can remove copy-pasted boilerplates.
llvm-svn: 234047
|
|
|
|
|
|
|
| |
result_type is no longer part of the type traits, so keeping it here
is confusing.
llvm-svn: 234044
|
|
|
|
|
|
|
|
|
| |
There is one-to-one correspondence between ELF machine type and a
LinkingContext. We passed them as separate arguments to the constructor.
This patch is to teach the LinkingContexts about their machine types,
so that we don't need to pass that data as separate arguments.
llvm-svn: 233894
|
|
|
|
| |
llvm-svn: 233316
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the LinkingContext parameter to the ELFReader. Previously the flags in
that were needed in the Context was passed to the ELFReader, this made it very
hard to access data structures in the LinkingContext when reading an ELF file.
This change makes the ELFReader more flexible so that required parameters can be
grabbed directly from the LinkingContext.
Future patches make use of the changes.
There is no change in functionality though.
llvm-svn: 228905
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch there was a cyclic dependency between lldCore and
lldReaderWriter. Only lldConfig could be built as a shared library.
* Moved Reader and Writer base classes into lldCore.
* The following shared libraries can now be built:
lldCore
lldYAML
lldNative
lldPasses
lldReaderWriter
Differential Revision: http://reviews.llvm.org/D7105
From: Greg Fitzgerald <garious@gmail.com>
llvm-svn: 226732
|
|
|
|
|
|
|
|
| |
The original commit had an issue with Mac OS dylib files. It didn't
handle fat binary dylib files correctly. This patch includes a fix.
A test for that case has already been committed in r225764.
llvm-svn: 226123
|
|
|
|
|
|
|
| |
r225764 broke a basic functionality on Mac OS. This change reverts
r225764, r225766, r225767, r225769, r225814, r225816, r225829, and r225832.
llvm-svn: 225859
|
|
|
|
| |
llvm-svn: 225764
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The documentation of parseFile() said that "the resulting File
object may take ownership of the MemoryBuffer." So, whether or not
the ownership of a MemoryBuffer would be taken was not clear.
A FileNode (a subclass of InputElement, which is being deprecated)
keeps the ownership if a File doesn't take it.
This patch makes File always take the ownership of a buffer.
Buffers lifespan is not always the same as File instances.
Files are able to deallocate buffers after parsing the contents.
llvm-svn: 224113
|
|
|
|
|
|
|
| |
The base class ELFObjectReader/ELFDSOReader implement the canParse functionaity
with this change.
llvm-svn: 220261
|
|
|
|
|
|
|
|
|
| |
This would permit the ELF reader to check the architecture that is being
selected by the linking process.
This patch also sorts the include files according to LLVM conventions.
llvm-svn: 220129
|
|
|
|
| |
llvm-svn: 212372
|
|
|
|
| |
llvm-svn: 210785
|
|
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209948
|
|
|
|
| |
llvm-svn: 205056
|
|
|
|
|
|
| |
No change in functionality.
llvm-svn: 200175
|
|
llvm-svn: 200173
|