summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/ELF/Hexagon/HexagonLinkingContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove the old ELF linker.Rafael Espindola2016-02-281-47/+0
| | | | | | I think it is clear by now that the new linker is viable. llvm-svn: 262158
* ELF: Remove redundant namespace qualifiers.Rui Ueyama2015-04-141-1/+1
| | | | llvm-svn: 234938
* ELF: Move function definitions from .h to .cpp.Rui Ueyama2015-04-141-3/+13
| | | | llvm-svn: 234863
* ELF: Merge ELFTargets.h with ELFLinkingContext.h.Rui Ueyama2015-04-041-1/+0
| | | | | | | | These functions are "constructors" of the LinkingContexts. We already have auxiliary classes and functions for ELFLinkingContext in the header. They fall in the same category. llvm-svn: 234082
* ELF: Remove partial class definitions of <Arch>LinkingContexts.Rui Ueyama2015-04-031-1/+2
| | | | | | | | | | | | | What we are doing in ELFTarget.h was dubious. In the file, we define partial classes of <Arch>LinkingContexts to declare only static member functions. We have different (complete) class definitions in other files. They would conflict if they exist in the same compilation unit (because the ones defined in ELFTarget.h has only static member functions). I don't think this was valid C++. http://reviews.llvm.org/D8797 llvm-svn: 234039
* ELF: Move registerRelocationNames() from TargetHandler to ↵Rui Ueyama2015-04-021-0/+13
| | | | | | | | | | | | | | | | | | | | | <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
* Use llvm::make_unique.Rui Ueyama2015-04-011-2/+1
| | | | llvm-svn: 233863
* ELF: Remove TargetHandlerBase by merging it with TargetHandler.Rui Ueyama2015-04-011-1/+1
| | | | | | | | | | | | | | | | | | | In r233772, I removed an empty class, DefaultTargetHandler, from the class hierarchy by merging the class with TargetHandler. I then found that TargetHandler and its base class, TargetHandlerBase, are also almost the same. We need to go deeper. In this patch, I merged TargetHandlerBase with TargetHandler. The only difference between them is the existence (or absense) of a pure virtual function registerRelocationName(). I added that function to the (new) TargetHandler. One more thing is that TargetHandler was templated for no reason. I made it non-templated class. llvm-svn: 233773
* Fix the ELF shared library build targets - take 2Greg Fitzgerald2015-01-241-0/+8
| | | | | | | | | | 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
* [ELF] Make -init/-fini options compatible with the gnu linkerSimon Atanasyan2014-12-101-89/+0
| | | | | | | | | | | | | | The LLD linker searches initializer and finalizer function names and emits DT_INIT/DT_FINI dynamic table tags to point to these symbols. The -init/-fini command line options override initializer ("_init") and finalizer ("_fini") function names used by default. Now the -init/-fini options do not affect .init_array/.fini_array sections. The corresponding code has been removed. Differential Revision: http://reviews.llvm.org/D6578 llvm-svn: 223917
* [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
* Move Simple.h and Alias.h to include/Core.Rui Ueyama2014-06-111-1/+1
| | | | | | | | Because the files in Core actually depend on these files. Differential Revision: http://reviews.llvm.org/D4000 llvm-svn: 210710
* Add "override" and remove "virtual" where appropriate.Rui Ueyama2014-03-061-4/+4
| | | | | | | For the record, I used clang-modernize to add "override" and perl to remove "virtual". llvm-svn: 203164
* [ELF] Add Target specific Readers.Shankar Easwaran2014-01-271-0/+5
| | | | | | No change in functionality. llvm-svn: 200175
* The return value of createInternalFiles is unused, so remove it.Joey Gouly2013-12-311-2/+1
| | | | llvm-svn: 198266
* Run clang-format on r197727.Rui Ueyama2013-12-201-1/+2
| | | | llvm-svn: 197788
* [lld] Introduce registry and Reference kind tupleNick Kledzik2013-12-191-154/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Layout] Dont set ordinals to Files by default.Shankar Easwaran2013-10-091-3/+3
| | | | | | | | | | | | | This change removes code in various places which was setting the File Ordinals. This is because the file ordinals are assigned by the way files are resolved. There was no other way than making the getNextFileAndOrdinal be set const and change the _nextOrdinal to mutable. There are so many places in code, that you would need to cleanup to make LinkingContext non-const! llvm-svn: 192280
* Update error classes from all lowercase to camel case.Rui Ueyama2013-10-091-2/+2
| | | | llvm-svn: 192261
* [lld][InputGraph] Change the Resolver to use inputGraphShankar Easwaran2013-10-071-10/+7
| | | | | | | | | | | | Changes :- a) Functionality in InputGraph to insert Input elements at any position b) Functionality in the Resolver to use nextFile c) Move the functionality of assigning file ordinals to InputGraph d) Changes all inputs to MemoryBuffers e) Remove LinkerInput, InputFiles, ReaderArchive llvm-svn: 192081
* [lld][ELF][Hexagon] add Init/Fini option for hexagonShankar Easwaran2013-09-031-0/+85
| | | | | | This adds init/fini support for Hexagon. llvm-svn: 189872
* Rename TargetInfo -> LinkingContext.Rui Ueyama2013-08-061-0/+170
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