| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is similar to D46290 D46320.
Reviewers: ruiu, grimar
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D46861
llvm-svn: 332372
|
|
|
|
|
|
|
|
|
|
| |
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.
Differential Revision: https://reviews.llvm.org/D37645
llvm-svn: 314719
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
|
|
|
|
|
|
|
|
| |
This would trigger an assertion at runtime otherwise.
Differential Revision: https://reviews.llvm.org/D26482
llvm-svn: 286562
|
|
|
|
|
|
|
|
| |
returning Expected<>
for the llvm trunk change in r277656
llvm-svn: 277657
|
|
|
|
|
|
| |
Where Archive::getMemoryBufferRef() was changed to return Expected<>
llvm-svn: 277183
|
|
|
|
| |
llvm-svn: 275362
|
|
|
|
|
|
| |
ErrorOr<...> to Expected<...> in r274160.
llvm-svn: 274161
|
|
|
|
| |
llvm-svn: 267010
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19348
llvm-svn: 267008
|
|
|
|
|
|
|
|
|
|
|
| |
searchArchivesToOverrideTentativeDefinitions and
searchSharedLibrariesToOverrideTentativeDefinitions are always false.
For the dead flags, we have a fairly large amount of code which is
never be executed.
http://reviews.llvm.org/D17791
llvm-svn: 264653
|
|
|
|
|
|
|
| |
Sorry had this fixed in my check out but failed mention it in my
commit message for r264187.
llvm-svn: 264188
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a re-commit of r264022 with a fix for MSVC. The issue there was
that the code was running DefinedAtom::~Atom() for some value and instead
needed to cast to Atom before running ~Atom. Original commit message follows.
Currently each File contains an BumpPtrAllocator in which Atom's are
allocated. Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.
Now each File actually owns its Atom's using an OwningAtomPtr. This
is analygous to std::unique_ptr and may be replaced by it if possible.
An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another. The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's. This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.
Should hopefully fix the remaining leaks. Will keep an eye on the bots to
make sure.
llvm-svn: 264067
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r264022.
This breaks the Window's bots which don't like that i'm calling ~Atom when
the this pointer is a sublcass of Atom.
Reverting for now until I try find a better fix. I tried using std::unique_ptr with
a custom deleter as a quick fix, but it didn't work well in the YAML parser.
llvm-svn: 264023
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently each File contains an BumpPtrAllocator in which Atom's are
allocated. Some Atom's contain data structures like std::vector which
leak as we don't run ~Atom when they are BumpPtrAllocate'd.
Now each File actually owns its Atom's using an OwningAtomPtr. This
is analygous to std::unique_ptr and may be replaced by it if possible.
An Atom can therefore only be owned by a single File, so the Resolver now
moves them from one File to another. The MachOLinkingContext owns the File's
and so clears all the Atom's in ~MachOLinkingContext, then delete's all the
File's. This makes sure all Atom's have been destructed before any of the
BumpPtrAllocator's in which they run have gone away.
Should hopefully fix the remaining leaks. Will keep an eye on the bots to
make sure.
llvm-svn: 264022
|
|
|
|
| |
llvm-svn: 262436
|
|
|
|
|
|
|
| |
makeErrorFile and parseMemberFiles are now used only in DarwinLdDriver.cpp.
This patch moves them to that file.
llvm-svn: 262423
|
|
|
|
|
|
| |
The preload feature was buggy that we had disabled it even for ELF.
llvm-svn: 262194
|
|
|
|
| |
llvm-svn: 262193
|
|
|
|
|
|
|
| |
in r252192 that changed the Archive and Child interfaces in libObject. These include
Rafael Espindola’s many suggested updates.
llvm-svn: 252193
|
|
|
|
|
|
| |
Patch from George Rimar!
llvm-svn: 248525
|
|
|
|
| |
llvm-svn: 242216
|
|
|
|
| |
llvm-svn: 241746
|
|
|
|
| |
llvm-svn: 241298
|
|
|
|
| |
llvm-svn: 240781
|
|
|
|
|
|
| |
This just reduces the noise from another patch.
llvm-svn: 235776
|
|
|
|
| |
llvm-svn: 235747
|
|
|
|
| |
llvm-svn: 235744
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Type names should start with an uppercase letter in the LLVM coding style.
llvm-svn: 234452
|
|
|
|
|
|
|
| |
Archive files don't have any symbols (their members do).
The vectors deleted here were always empty.
llvm-svn: 234368
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
File objects are not really const in the resolver. We set ordinals to
them and call beforeLink hooks. Also, File's member functions marked
as const are not really const. ArchiveFile never returns the same
member file twice, so it remembers files returned before. find() has
side effects.
In order to deal with the inconsistencies, we sprinkled const_casts
and marked member varaibles as mutable.
This patch removes const from there to reflect the reality.
llvm-svn: 231212
|
|
|
|
|
|
| |
This reverts accidental commit r231205.
llvm-svn: 231208
|
|
|
|
|
|
|
| |
This patch moves local variable definitions so that their scope get narrower.
Also uses range-based loop. Both are for readability.
llvm-svn: 231206
|
|
|
|
| |
llvm-svn: 231205
|
|
|
|
| |
llvm-svn: 231196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
std::promise and std::future in old version of libstdc++ are buggy.
I think that's the reason why LLD tests were flaky on Ubuntu 13
buildbots until we disabled file preloading.
In this patch, I implemented very simple future and used that in
FileArchive. Compared to std::promise and std::future, it lacks
many features, but should serve our purpose.
http://reviews.llvm.org/D8025
llvm-svn: 231153
|
|
|
|
|
|
|
|
|
| |
"virtual" was present at a wrong place. FileArchive is a subclass of
ArchiveLibraryFile, and a FileArchive can be deleted through a
pointer of ArchiveLibraryFile. We want to make the destructor of the
base class virtual.
llvm-svn: 231033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we only have File::path() to get the path name of a file.
If a file was a member of an archive file, path() returns a concatenated
string of the file name in the archive and the archive file name.
If we wanted to get a file name or an archive file name, we had to
parse that string. That's of course not good.
This patch adds new member functions, archivePath and memberPath, to File.
http://reviews.llvm.org/D7447
llvm-svn: 228352
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLD parses archive file index table only at first. When it finds a symbol
it is looking for is defined in a member file in an archive file, it actually
reads the member from the archive file. That's done in the core linker.
That's a single-thread process since the core linker is single threaded.
If your command line contains a few object files and a lot of archive files
(which is quite often the case), LLD hardly utilizes hardware parallelism.
This patch improves parallelism by speculatively instantiating archive
file members. At the beginning of the core linking, we first create a map
containing all symbols defined in all members, and each time we find a
new undefined symbol, we instantiate a member file containing the
symbol (if such file exists). File instantiation is side effect free, so this
should not affect correctness.
This is a quick benchmark result. Time to link self-link LLD executable:
Linux 9.78s -> 8.50s (0.86x)
Windows 6.18s -> 4.51s (0.73x)
http://reviews.llvm.org/D7015
llvm-svn: 226336
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This field was not even initialized properly.
llvm-svn: 224236
|
|
|
|
| |
llvm-svn: 224235
|
|
|
|
|
|
| |
Core/File.h does not use LinkingContext.h, so remove that dependency.
llvm-svn: 224214
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a second patch for InputGraph cleanup.
Sorry about the size of the patch, but what I did in this
patch is basically moving code from constructor to a new
method, parse(), so the amount of new code is small.
This has no change in functionality.
We've discussed the issue that we have too many classes
to represent a concept of "file". We have File subclasses
that represent files read from disk. In addition to that,
we have bunch of InputElement subclasses (that are part
of InputGraph) that represent command line arguments for
input file names. InputElement is a wrapper for File.
InputElement has parseFile method. The method instantiates
a File. The File's constructor reads a file from disk and
parses that.
Because parseFile method is called from multiple worker
threads, file parsing is processed in parallel. In other
words, one reason why we needed the wrapper classes is
because a File would start reading a file as soon as it
is instantiated.
So, the reason why we have too many classes here is at
least partly because of the design flaw of File class.
Just like threads in a good threading library, we need
to separate instantiation from "start" method, so that
we can instantiate File objects when we need them (which
should be very fast because it involves only one mmap()
and no real file IO) and use them directly instead of
the wrapper classes. Later, we call parse() on each
file in parallel to let them do actual file IO.
In this design, we can eliminate a reason to have the
wrapper classes.
In order to minimize the size of the patch, I didn't go so
far as to replace the wrapper classes with File classes.
The wrapper classes are still there.
In this patch, we call parse() immediately after
instantiating a File, so this really has no change in
functionality. Eventually the call of parse() should be
moved to Driver::link(). That'll be done in another patch.
llvm-svn: 224102
|