summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/ELF/DynamicFile.h
Commit message (Collapse)AuthorAgeFilesLines
* Remove the old ELF linker.Rafael Espindola2016-02-281-59/+0
| | | | | | I think it is clear by now that the new linker is viable. llvm-svn: 262158
* Use MemoryBufferRef instead of MemoryBuffer&. NFC.Rafael Espindola2015-04-271-1/+1
| | | | | | This just reduces the noise from another patch. llvm-svn: 235933
* Remove dead code.Rui Ueyama2015-04-141-3/+0
| | | | llvm-svn: 234854
* ELF: Remove ELFT and LinkingContext template parameters from ELFReader.Rui Ueyama2015-04-141-0/+3
| | | | | | | | | | | | | | | | | | | 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
* ELF: Move definitions from {Dynamic,ELF}File.h to .cpp files.Rui Ueyama2015-04-131-75/+8
| | | | | | | | | | | | | | | | | | | DynamicFile and ELFFile are instantiated for four different types, ELF{32,64}{BE,LE}. Because the classes are instantiated in each compilation unit, including the header file makes object files 10MB larger. On Windows, issue of excessive template instantiation is critical, since the regular COFF file supports only up to 65534 sections. (We could use the extended COFF file format, but generating that much COMDAT sections is not a good thing in the first place because it means long compile time and long link time.) I confirmed that this change makes AArch64TargetHandler.cpp.o from 21MB to 8.5MB. It feels still too large, but I think it's a good start. llvm-svn: 234808
* Separate atom_collection type into two different types. NFC.Rui Ueyama2015-04-081-1/+1
| | | | | | | | | | | | | | | | | | | | atom_collection is basically a wrapper for std::vector. The class provides begin and end member functions, so that it "hides" the other member functions provided by std::vector. However, you can still directly access _atoms member since the member is not protected. We cannot simply make the member private because we need that member when we are constructing atom vectors. This patch splits atom_collection into two types: std::vector<Atom *> and AtomRange. When we are constructing atom vectors, we use the former class. We return instances of the latter class from File objects so that callers cannot add or remove atoms from the lists. std::vector<Atom *> is automatically converted to AtomRange. llvm-svn: 234450
* ELF: Teach File classes about their file magics.Rui Ueyama2015-04-041-0/+4
| | | | | | | | 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
* ELF: Pass file types instead of type traits to ELFObjectReader.Rui Ueyama2015-04-031-4/+4
| | | | | | | | 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
* Use C++ non-static member initialization.Rui Ueyama2015-04-011-3/+2
| | | | llvm-svn: 233859
* [ELF] Dont add local symbols for dynamic lookup.Shankar Easwaran2015-03-201-0/+5
| | | | | | | Unable to add a unit test for this, as there is only one local undefined symbol in regular shared libraries without a name. llvm-svn: 232867
* [ELF] Add LinkingContext to the ELFReader.Shankar Easwaran2015-02-121-7/+7
| | | | | | | | | | | | | | | 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
* [ELF] Dont release ownership of MemoryBuffer.Shankar Easwaran2015-02-051-1/+1
| | | | | | MemoryBuffer is being released too early. ELFFile owns MemoryBuffer. llvm-svn: 228260
* Move common code to base class.Rui Ueyama2015-01-161-20/+0
| | | | llvm-svn: 226329
* [ELF] Add --as-needed.Rui Ueyama2015-01-161-0/+2
| | | | | | | | | | | | The previous default behavior of LLD is --as-needed. LLD linked against a DSO only if the DSO file was actually used to link an executable (i.e. at least one symbol was resolved using the shared library file.) In this patch I added a boolean flag to FileNode for --as-needed. I also added an accessor to DSO name to shared library file class. llvm-svn: 226274
* Protect doParse() because that's not a public interface.Rui Ueyama2014-12-151-0/+1
| | | | llvm-svn: 224235
* Separate file parsing from File's constructors.Rui Ueyama2014-12-121-44/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF] Add Readers for all the ELF subtargets.Shankar Easwaran2014-10-181-3/+0
| | | | | | | | | 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
* Update for llm api change.Rafael Espindola2014-07-051-1/+2
| | | | llvm-svn: 212372
* Don't import error_code into the lld namespace.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210785
* [ELF] Add "override" and remove "virtual".Rui Ueyama2014-03-281-6/+6
| | | | llvm-svn: 205056
* [ELF] Add Target specific Readers.Shankar Easwaran2014-01-271-1/+1
| | | | | | No change in functionality. llvm-svn: 200175
* [ELF] Separate implementation from the class declaration.Shankar Easwaran2014-01-261-46/+50
| | | | | | | | ELFFile would be a class that rest of the targets would derive from. To keep the implementation clean, separate the implementation from rest of the Header file. llvm-svn: 200168
* Use getError instead of the error_code operator.Rafael Espindola2014-01-081-2/+2
| | | | llvm-svn: 198797
* Run clang-format on r197727.Rui Ueyama2013-12-201-3/+2
| | | | llvm-svn: 197788
* [lld] Introduce registry and Reference kind tupleNick Kledzik2013-12-191-11/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main changes are in: include/lld/Core/Reference.h include/lld/ReaderWriter/Reader.h Everything else is details to support the main change. 1) Registration based Readers Previously, lld had a tangled interdependency with all the Readers. It would have been impossible to make a streamlined linker (say for a JIT) which just supported one file format and one architecture (no yaml, no archives, etc). The old model also required a LinkingContext to read an object file, which would have made .o inspection tools awkward. The new model is that there is a global Registry object. You programmatically register the Readers you want with the registry object. Whenever you need to read/parse a file, you ask the registry to do it, and the registry tries each registered reader. For ease of use with the existing lld code base, there is one Registry object inside the LinkingContext object. 2) Changing kind value to be a tuple Beside Readers, the registry also keeps track of the mapping for Reference Kind values to and from strings. Along with that, this patch also fixes an ambiguity with the previous Reference::Kind values. The problem was that we wanted to reuse existing relocation type values as Reference::Kind values. But then how can the YAML write know how to convert a value to a string? The fix is to change the 32-bit Reference::Kind into a tuple with an 8-bit namespace (e.g. ELF, COFFF, etc), an 8-bit architecture (e.g. x86_64, PowerPC, etc), and a 16-bit value. This tuple system allows conversion to and from strings with no ambiguities. llvm-svn: 197727
* A weak reference to a symbol that is only weakly referenced inJoerg Sonnenberger2013-09-031-1/+3
| | | | | | dependencies should remain weak, not get promoted to undef or dropped. llvm-svn: 189793
* Rename ti -> ctx.Rui Ueyama2013-08-271-3/+3
| | | | | | | This should have been done in r187823 when I renamed LinkingContext from TargetInfo. I missed a few files. llvm-svn: 189298
* Update to llvm changes.Michael J. Spencer2013-08-081-23/+16
| | | | llvm-svn: 188021
* Rename TargetInfo -> LinkingContext.Rui Ueyama2013-08-061-8/+10
| | | | | | | | | Also change some local variable names: "ti" -> "context" and "_targetInfo" -> "_context". Differential Revision: http://llvm-reviews.chandlerc.com/D1301 llvm-svn: 187823
* This adds functionality for undefined atoms from dynamic libraries to be addedShankar Easwaran2013-04-111-9/+20
| | | | | | | | | | | | to the list of undefined atoms. The processing of undefined atoms from dynamic libraries is controlled by use-shlib-undefines command line option. This patch also adds additional command line arguments to allow/disallow unresolved symbols from shared libraries and mimics GNU ld behavior. llvm-svn: 179257
* Set ordinals correctly.Michael J. Spencer2013-03-201-4/+0
| | | | | | | This actually doesn't change behavior with the current LinkerInvocation, but it's needed when you make reading parallel. llvm-svn: 177554
* [ELF] Fix memory leak by deleting BumpPtr allocated objects.Michael J. Spencer2013-02-191-4/+4
| | | | llvm-svn: 175558
* [Core,Driver,ELF] Differentiate static and dynamic executables.Michael J. Spencer2013-02-141-2/+3
| | | | | | | This also adds a simple relocation change for dynamic executables to x86-64 ELF. llvm-svn: 175208
* [ELF] Add support for reading dynamic libraries.Michael J. Spencer2013-02-111-0/+132
llvm-svn: 174916
OpenPOWER on IntegriCloud