summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/ELF/X86/X86LinkingContext.h
Commit message (Collapse)AuthorAgeFilesLines
* Remove the old ELF linker.Rafael Espindola2016-02-281-44/+0
| | | | | | I think it is clear by now that the new linker is viable. llvm-svn: 262158
* ELF: Remove ELFT and LinkingContext template parameters from ELFReader.Rui Ueyama2015-04-141-1/+1
| | | | | | | | | | | | | | | | | | | 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: Remove a template parameter from ELF{Object,DOS}Reader constructors.Rui Ueyama2015-04-021-0/+1
| | | | | | | | | 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
* ELF: Move registerRelocationNames() from TargetHandler to ↵Rui Ueyama2015-04-021-0/+1
| | | | | | | | | | | | | | | | | | | | | <Arch>ELFLinkingContext. registerRelocationNames() function is called to register all known ELF relocation types to the central registry. Since we have separate LinkingContext class for each ELF machine type, we need to call the function for each LinkingContext. However, the function belonged to TargetHandler instead of LinkingContext. So we needed to do ctx.getTargetHandler().registerRelocationNames(). This patch removes that redundant getTargetHandler call by moving the function from TargetHandler to LinkingContext. Conceptually this patch is small, but in reality it's not that small. It's because the same code is copied to each architecture. Most of this patch is just repetition. We need to merge them, but that cannot be done in this patch. llvm-svn: 233883
* [Revert] [ELF] Determine default search directories from ContextShankar Easwaran2015-02-061-9/+0
| | | | | | | It looks like the Driver manages search path for each Target lld would support on the Gnu flavor. llvm-svn: 228440
* [ELF] Determine default search directories from Context.Shankar Easwaran2015-02-021-0/+9
| | | | | | | | Target specific LinkingContext's determine the default search directory. No change in functionality. llvm-svn: 227784
* Fix the ELF shared library build targets - take 2Greg Fitzgerald2015-01-241-4/+2
| | | | | | | | | | lldELF is used by each ELF backend. lldELF's ELFLinkingContext also held a reference to each backend, creating a link-time cycle. This patch moves the backend references to lldDriver. Differential Revision: http://reviews.llvm.org/D7119 llvm-svn: 226976
* Revert " Fix the ELF shared library build targets"Greg Fitzgerald2015-01-231-1/+4
| | | | | | This reverts commit 6a3f545b44cea46321e025d9ab773786af86cb51. llvm-svn: 226928
* Fix the ELF shared library build targetsGreg Fitzgerald2015-01-231-4/+1
| | | | | | | | | | lldELF is used by each ELF backend. lldELF's ELFLinkingContext also held a reference to each backend, creating a link-time cycle. This patch moves the backend references to lldDriver. Differential Revision: http://reviews.llvm.org/D7119 llvm-svn: 226922
* [ELF] Remove is64bits() and isLittlEndian().Shankar Easwaran2014-11-071-4/+0
| | | | | | | | | | ELFLinkingContext had these two functions, which is really not needed since the Writer uses a llvm::object template composed of Endianness, Alignment, Is32bit/64bit. We could just use that and not duplicate functionality. No Change In Functionality. llvm-svn: 221523
* [ELF] Implement isLittleEndian for all architecturesShankar Easwaran2014-11-061-0/+4
| | | | llvm-svn: 221427
* [ELF] Add Readers for all the ELF subtargets.Shankar Easwaran2014-10-181-2/+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
* [ELF] Add "override" and remove "virtual".Rui Ueyama2014-03-281-1/+1
| | | | llvm-svn: 205056
* [C++11] Switch from LLVM_FINAL to just "final" now that all of LLVM isChandler Carruth2014-03-021-1/+1
| | | | | | requiring MSVC 2012 or newer. llvm-svn: 202626
* [lld] Introduce registry and Reference kind tupleNick Kledzik2013-12-191-3/+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
* Rename TargetInfo -> LinkingContext.Rui Ueyama2013-08-061-0/+45
Also change some local variable names: "ti" -> "context" and "_targetInfo" -> "_context". Differential Revision: http://llvm-reviews.chandlerc.com/D1301 llvm-svn: 187823
OpenPOWER on IntegriCloud