summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/FileArchive.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix builds broken in r267008.Eugene Zelenko2016-04-211-0/+1
| | | | llvm-svn: 267010
* Fix Clang-tidy misc-unused-using-decls and Include What You Use warnings.Eugene Zelenko2016-04-211-10/+12
| | | | | | Differential revision: http://reviews.llvm.org/D19348 llvm-svn: 267008
* Remove dead flags.Rui Ueyama2016-03-281-44/+1
| | | | | | | | | | | 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
* Add the needed lld change for r264187 in llvm.Kevin Enderby2016-03-231-1/+4
| | | | | | | Sorry had this fixed in my check out but failed mention it in my commit message for r264187. llvm-svn: 264188
* Use owning pointers instead of raw pointers for Atom's to fix leaks.Pete Cooper2016-03-221-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Use owning pointers instead of raw pointers for Atom's to fix leaks."Pete Cooper2016-03-221-11/+4
| | | | | | | | | | | | 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
* Use owning pointers instead of raw pointers for Atom's to fix leaks.Pete Cooper2016-03-221-4/+11
| | | | | | | | | | | | | | | | | | | | 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
* Remove dead code.Rui Ueyama2016-03-021-2/+0
| | | | llvm-svn: 262436
* Make a few utility functions file-scoped.Rui Ueyama2016-03-011-1/+1
| | | | | | | makeErrorFile and parseMemberFiles are now used only in DarwinLdDriver.cpp. This patch moves them to that file. llvm-svn: 262423
* Remove dead code for ELF.Rui Ueyama2016-02-281-45/+0
| | | | | | The preload feature was buggy that we had disabled it even for ELF. llvm-svn: 262194
* Remove remaining code for COFF.Rui Ueyama2016-02-281-9/+0
| | | | llvm-svn: 262193
* These are the matching changes needed to the lld project for the changes to llvmKevin Enderby2015-11-051-12/+22
| | | | | | | in r252192 that changed the Archive and Child interfaces in libObject. These include Rafael Espindola’s many suggested updates. llvm-svn: 252193
* Fix memory leak in FileArchive::find().Rui Ueyama2015-09-241-2/+7
| | | | | | Patch from George Rimar! llvm-svn: 248525
* Update for llvm api change.Rafael Espindola2015-07-141-3/+9
| | | | llvm-svn: 242216
* Update for upcoming llvm change.Rafael Espindola2015-07-081-1/+1
| | | | llvm-svn: 241746
* Update for llvm changes.Rafael Espindola2015-07-021-3/+3
| | | | llvm-svn: 241298
* Update for llvm changes.Rafael Espindola2015-06-261-3/+1
| | | | llvm-svn: 240781
* Use MemoryBufferRef instead of MemoryBuffer&. NFC.Rafael Espindola2015-04-241-1/+1
| | | | | | This just reduces the noise from another patch. llvm-svn: 235776
* Simplify now that there is only one file. NFC.Rafael Espindola2015-04-241-4/+1
| | | | llvm-svn: 235747
* Return ErrorOr<std::unique_ptr<File>>. NFC.Rafael Espindola2015-04-241-3/+4
| | | | llvm-svn: 235744
* Return an ErrorOr<std::unique_ptr<File>>. NFC.Rafael Espindola2015-04-241-5/+4
| | | | llvm-svn: 235741
* Delete unnecessary generality in loadFile.Rafael Espindola2015-04-241-8/+9
| | | | | | | | | | | | | 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
* Rename atom_collection -> AtomVector.Rui Ueyama2015-04-081-4/+4
| | | | | | Type names should start with an uppercase letter in the LLVM coding style. llvm-svn: 234452
* Remove unused vectors from FileArchive.Rui Ueyama2015-04-071-8/+4
| | | | | | | Archive files don't have any symbols (their members do). The vectors deleted here were always empty. llvm-svn: 234368
* Remove a parameter for file extension from canParse.Rui Ueyama2015-04-041-3/+2
| | | | | | | | 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
* Make File non-const in the resolver.Rui Ueyama2015-03-041-10/+10
| | | | | | | | | | | | | | | 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
* Revert "temporary"Rui Ueyama2015-03-041-22/+8
| | | | | | This reverts accidental commit r231205. llvm-svn: 231208
* Simplify FileArchive. NFC.Rui Ueyama2015-03-041-23/+15
| | | | | | | This patch moves local variable definitions so that their scope get narrower. Also uses range-based loop. Both are for readability. llvm-svn: 231206
* temporaryRui Ueyama2015-03-041-8/+22
| | | | llvm-svn: 231205
* Make a private function private.Rui Ueyama2015-03-041-21/+20
| | | | llvm-svn: 231196
* Implement our own future and use that for FileArchive::preload().Rui Ueyama2015-03-031-13/+9
| | | | | | | | | | | | | | 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
* Make ArchiveLibraryFile::~ArchiveLibraryFile virtual.Rui Ueyama2015-03-021-2/+0
| | | | | | | | | "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
* Add methods to get archive file name from member file.Rui Ueyama2015-02-051-1/+2
| | | | | | | | | | | | | | 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
* [PATCH] Speculatively instantiate archive membersRui Ueyama2015-01-161-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Re-commit r225674: Convert other drivers to use WrapperNode.Rui Ueyama2015-01-151-4/+9
| | | | | | | | 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
* Revert "Convert other drivers to use WrapperNode" and subsequent commits.Rui Ueyama2015-01-141-9/+4
| | | | | | | r225764 broke a basic functionality on Mac OS. This change reverts r225764, r225766, r225767, r225769, r225814, r225816, r225829, and r225832. llvm-svn: 225859
* Convert other drivers to use WrapperNode.Rui Ueyama2015-01-131-4/+9
| | | | llvm-svn: 225764
* Remove dead code.Rui Ueyama2014-12-151-4/+0
| | | | | | This field was not even initialized properly. llvm-svn: 224236
* Protect doParse() because that's not a public interface.Rui Ueyama2014-12-151-11/+12
| | | | llvm-svn: 224235
* Clean up #include dependency.Rui Ueyama2014-12-141-0/+1
| | | | | | Core/File.h does not use LinkingContext.h, so remove that dependency. llvm-svn: 224214
* Make File always take the ownership of a MemoryBuffer.Rui Ueyama2014-12-121-14/+11
| | | | | | | | | | | | | | 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
* Separate file parsing from File's constructors.Rui Ueyama2014-12-121-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix FileArchive member MemoryBuffer early destructionNick Kledzik2014-11-071-6/+16
| | | | | | | | | | | | | | | When FileArchive loads a member, it instantiates a temporary MemoryBuffer which points to the member range of the archive file. The problem is that the object file parsers call getBufferIndentifer() on that temporary MemoryBuffer and store that StringRef as the _path data member for that lld::File. When FileArchive::instantiateMember() goes out of scope the MemoryBuffer is deleted and the File::._path becomes a dangling reference. The fix adds a vector<> to FileArchive to own the instantiated MemoryBuffers. In addition it fixes member's path to be the standard format (e.g. "/path/libfoo.a(foo.o)") instead of just the leaf name. llvm-svn: 221544
* Fix display of files processed by the linker.Shankar Easwaran2014-10-181-1/+3
| | | | | | | | | | This fixes the way archive members are displayed when the linker is used with a flag to show all the files that it processes. When an archive file member is read, we need to show the archive filename and the member. llvm-svn: 220144
* Sort include files according to convention.Shankar Easwaran2014-10-181-2/+0
| | | | llvm-svn: 220131
* Always check that instantiateMember returns only one file.Rui Ueyama2014-09-111-9/+12
| | | | | | Also make it private as it doesn't have to be protected function. llvm-svn: 217626
* FileArchive cleanupRui Ueyama2014-09-051-25/+19
| | | | | | | | | Moved code used only by isDataSymbol from find to isDataSymbol member function. Also changed the return type of isDataSymbol because previously "if (isDataSymbol(...))" meant "if it is *not* a data symbol" which is opposite from what you'd expect. llvm-svn: 217285
* Update for llvm api change.Rafael Espindola2014-08-191-10/+17
| | | | llvm-svn: 216003
* Update for llvm api change.Rafael Espindola2014-07-311-1/+1
| | | | llvm-svn: 214378
* Update for llvm api change.Rafael Espindola2014-06-241-5/+3
| | | | llvm-svn: 211596
OpenPOWER on IntegriCloud