summaryrefslogtreecommitdiffstats
path: root/lld/lib/ReaderWriter/YAML/ReaderWriterYAML.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix five of the shared library build targetsGreg Fitzgerald2015-01-211-2/+2
| | | | | | | | | | | | | | | | | | Before this patch there was a cyclic dependency between lldCore and lldReaderWriter. Only lldConfig could be built as a shared library. * Moved Reader and Writer base classes into lldCore. * The following shared libraries can now be built: lldCore lldYAML lldNative lldPasses lldReaderWriter Differential Revision: http://reviews.llvm.org/D7105 From: Greg Fitzgerald <garious@gmail.com> llvm-svn: 226732
* Re-commit r225674: Convert other drivers to use WrapperNode.Rui Ueyama2015-01-151-4/+4
| | | | | | | | 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-4/+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/+4
| | | | llvm-svn: 225764
* Make YAML files own MemoryBuffer.Rui Ueyama2014-12-131-5/+2
| | | | | | | YAML files have references such as StringRef to the underlying MemoryBuffer, so we shouldn't deallocate the buffer. llvm-svn: 224191
* Make File always take the ownership of a MemoryBuffer.Rui Ueyama2014-12-121-7/+5
| | | | | | | | | | | | | | 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-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Follow-up to r221913. Fix some -Wcast-qual warning reasons.Simon Atanasyan2014-11-141-24/+26
| | | | llvm-svn: 221974
* [ELF] Add CodeModel attribute to the DefinedAtom classSimon Atanasyan2014-11-131-0/+14
| | | | | | | | | | | | | | | | | | | | | | MIPS ELF symbols might contain some additional MIPS-specific flags in the st_other field besides visibility ones. These flags indicate code properties like microMIPS / MIPS16 encoding, position independent code etc. We need to transfer the flags from input objects to the output linked file to write them into the symbol table, adjust symbols addresses etc. I add new attribute CodeModel to the DefinedAtom class to hold target specific flag and to get over YAML/Native format conversion barrier. Other architectures/targets can extend CodeModel enumeration by their own flags. MIPS specific part of this patch adds support for STO_MIPS_MICROMIPS flag. This flag marks microMIPS symbols. Such symbol should: a) Has STO_MIPS_MICROMIPS in the corresponding .symtab record. b) Has adjusted (odd) address in the corresponding .symtab and .dynsym records. llvm-svn: 221864
* [mach-o] Support linker synthesized mach_header symbols.Nick Kledzik2014-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | On darwin in final linked images, the __TEXT segment covers that start of the file. That means in memory a process can see the mach_header (and load commands) for every loaded image in a process. There are APIs that take and return the mach_header addresses as a way to specify a particular loaded image. For completeness, any code can get the address of the mach_header of the image it is in by using &__dso_handle. In addition there are mach-o type specific symbols like __mh_execute_header. The linker needs to supply a definition for any of these symbols if used. But the address the symbol it resolves to is not in any section. Instead it is the address of the start of the __TEXT segment. I needed to make a small change to SimpleFileNode to not override resetNextIndex() because the Driver creates a SimpleFileNode to hold the internal/implicit files that the context/writer can create. For some reason SimpleFileNode overrode resetNextIndex() to do nothing instead of reseting the index (which mach-o needs if the internal file is an archive). llvm-svn: 221822
* [mach-o] Add support for interposing tuples sectionNick Kledzik2014-11-061-0/+2
| | | | | | | | | | Darwin uses two-level-namespace lookup for symbols which means the static linker records where each symbol must be found at runtime. Thus defining a symbol in a dylib loaded earlier will not effect where symbols needed by later dylibs will be found. Instead overriding is done through a section of type S_INTERPOSING which contains tuples of <interposer, interposee>. llvm-svn: 221421
* Fix leak found by asan.Rafael Espindola2014-11-031-4/+4
| | | | llvm-svn: 221180
* [mach-o] create __unwind_info section on x86_64Tim Northover2014-09-301-0/+1
| | | | | | | | | | | This is a minimally useful pass to construct the __unwind_info section in a final object from the various __compact_unwind inputs. Currently it doesn't produce any compressed pages, only works for x86_64 and will fail if any function ends up without __compact_unwind. rdar://problem/18208653 llvm-svn: 218703
* Update for LLVM api changeRafael Espindola2014-08-251-4/+4
| | | | llvm-svn: 216395
* References cannot be bound to null.Joerg Sonnenberger2014-07-171-2/+0
| | | | llvm-svn: 213323
* Update for llvm api change.Rafael Espindola2014-06-131-1/+2
| | | | llvm-svn: 210919
* include system_error directly.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210801
* Run llvm/utils/sort_includes.py in a few files.Rafael Espindola2014-06-121-2/+0
| | | | | | This will reduce the noise in a followup patch. llvm-svn: 210800
* Don't import error_code into the lld namespace.Rafael Espindola2014-06-121-5/+5
| | | | llvm-svn: 210785
* Don't use make_error_code from the llvm namespace.Rafael Espindola2014-06-121-1/+1
| | | | llvm-svn: 210741
* Move Simple.h and Alias.h to include/Core.Rui Ueyama2014-06-111-5/+4
| | | | | | | | Because the files in Core actually depend on these files. Differential Revision: http://reviews.llvm.org/D4000 llvm-svn: 210710
* Use std::error_code instead of llvm::error_code.Rafael Espindola2014-06-111-1/+1
| | | | | | This is an update for a llvm api change. llvm-svn: 210689
* Remove dead parameter.Rui Ueyama2014-06-091-3/+3
| | | | llvm-svn: 210461
* Remove group-parent references.Rui Ueyama2014-06-031-57/+13
| | | | | | | | | | | | | | | | | | | Previously section groups are doubly linked to their children. That is, an atom representing a group has group-child references to its group contents, and content atoms also have group-parent references to the group atom. That relationship was invariant; if X has a group-child edge to Y, Y must have a group-parent edge to X. However we were not using group-parent references at all. The resolver only needs group-child edges. This patch simplifies the section group by removing the unused reverse edge. No functionality change intended. Differential Revision: http://reviews.llvm.org/D3945 llvm-svn: 210066
* Use error_code() instead of error_code::succes()Rafael Espindola2014-05-311-2/+2
| | | | | | | There is no std::error_code::success, so this removes much of the noise in transitioning to std::error_code. llvm-svn: 209948
* Re-submit r207884: Remove dead codeRui Ueyama2014-05-051-1/+0
| | | | | | Differential Revision: http://reviews.llvm.org/D3599 llvm-svn: 207989
* Revert "Remove dead code."Rui Ueyama2014-05-021-0/+1
| | | | | | This reverts commit r207884 which was prematurely committed by accident. llvm-svn: 207886
* Remove dead code.Rui Ueyama2014-05-021-1/+0
| | | | | | | | | | | | | | | isAlias always returns false and no one is using it. It was originally added Atom to query if an atom is an alias for another atom, assuming that alias atoms are different from normal atoms. We now support atom aliasing, but the way that's implemented is in a different way than what isAlias assumed. An alias atom is just a regular defined atom with no content, and it has a layout- before edge to alias-to atom so that they are layed out at the same location in the result. So this is dead code, and it doesn't make much sense to keep it. llvm-svn: 207884
* Update to match changes made in r205955David Majnemer2014-04-101-0/+6
| | | | llvm-svn: 205956
* [core] support .gnu.linkonce sectionsShankar Easwaran2014-04-011-2/+3
| | | | | | | | | | | | | | | | | | .gnu.linkonce sections are similar to section groups. They were supported before section groups existed and provided a way to resolve COMDAT sections using a different design. There are few implementations that use .gnu.linkonce sections to store simple floating point constants which doesnot require complex section group support but need a way to store only one copy of the floating point constant in a binary. .gnu.linkonce based symbol resolution achieves that. Review : http://llvm-reviews.chandlerc.com/D3242 llvm-svn: 205280
* Revert "[core] support .gnu.linkonce sections"Shankar Easwaran2014-03-311-7/+3
| | | | | | | | | This reverts commit 5d5ca72a7876c3dd3dd1db83dc6a0d74be9e2cd1. Discuss on a better design to raise error when there is a similar group with Gnu linkonce sections and COMDAT sections. llvm-svn: 205224
* [core] support .gnu.linkonce sectionsShankar Easwaran2014-03-311-3/+7
| | | | | | | | | | | .gnu.linkonce sections are similar to section groups. They were supported before section groups existed and provided a way to resolve COMDAT sections using a different design. There are few implementations that use .gnu.linkonce sections to store simple floating point constants which doesnot require complex section group support but need a way to store only one copy of the floating point constant. .gnu.linkonce based symbol resolution achieves that. llvm-svn: 205163
* [core] add SectionGroup supportShankar Easwaran2014-03-261-5/+97
| | | | | | Review : http://llvm-reviews.chandlerc.com/D3182 llvm-svn: 204830
* [PECOFF] Support yet another new type of weak symbol.Rui Ueyama2014-03-181-0/+1
| | | | | | | | | | COMDAT_SELECT_LARGEST is a COMDAT type that make linker to choose the largest definition from among all of the definition of a symbol. If the size is the same, the choice is arbitrary. Differential Revision: http://llvm-reviews.chandlerc.com/D3011 llvm-svn: 204172
* Replace OwningPtr with std::unique_ptr.Ahmed Charles2014-03-131-1/+1
| | | | | | | | This results in some simplifications to the code where an OwningPtr had to be used with the previous api and then ownership moved to a unique_ptr for the rest of lld. llvm-svn: 203809
* [Cleanup] Sort includes.Ahmed Charles2014-03-121-1/+1
| | | | llvm-svn: 203666
* [PECOFF] Support a new type of weak symbol.Rui Ueyama2014-03-071-1/+3
| | | | | | | | | | | | | | | Summary: COMDAT_SELECT_SAME_SIZE is a COMDAT type that I presume exist only in COFF. The semantics of the type is that linker should merge such COMDAT sections if their sizes are the same. Otherwise it's an error. Reviewers: Bigcheese, shankarke, kledzik CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D2996 llvm-svn: 203308
* Add "override" and remove "virtual" where appropriate.Rui Ueyama2014-03-061-56/+56
| | | | | | | For the record, I used clang-modernize to add "override" and perl to remove "virtual". llvm-svn: 203164
* Update for LLVM api change.Rafael Espindola2014-02-241-1/+1
| | | | llvm-svn: 202054
* Don't assume that F_None is the default. It is about to change.Rafael Espindola2014-02-241-1/+1
| | | | llvm-svn: 202039
* Accept and handle absolute symbols with empty name.Simon Atanasyan2014-02-061-1/+2
| | | | llvm-svn: 200911
* Fix trailing whitespace.Shankar Easwaran2014-01-271-4/+4
| | | | llvm-svn: 200182
* Fix spacingNick Kledzik2014-01-131-2/+2
| | | | llvm-svn: 199074
* [yaml] use BumpPtrAllocator for string copiesNick Kledzik2014-01-111-22/+12
| | | | llvm-svn: 198987
* [mach-o] enable mach-o and native yaml to be intermixedNick Kledzik2014-01-111-17/+38
| | | | | | | | | | | | | | | | | | The main goal of this patch is to allow "mach-o encoded as yaml" and "native encoded as yaml" documents to be intermixed. They are distinguished via yaml tags at the start of the document. This will enable all mach-o test cases to be written using yaml instead of checking in object files. The Registry was extend to allow yaml tag handlers to be registered. The mach-o Reader adds a yaml tag handler for the tag "!mach-o". Additionally, this patch fixes some buffer ownership issues. When parsing mach-o binaries, the mach-o atoms can have pointers back into the memory mapped .o file. But with yaml encoded mach-o, name and content are ephemeral, so a copyRefs parameter was added to cause the mach-o atoms to make their own copy. llvm-svn: 198986
* Restore vertical alignment lost by clang-formatNick Kledzik2013-12-201-170/+167
| | | | llvm-svn: 197834
* Run clang-format on r197727.Rui Ueyama2013-12-201-35/+26
| | | | llvm-svn: 197788
* [lld] Introduce registry and Reference kind tupleNick Kledzik2013-12-191-117/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PECOFF] Refactor IdataPass.Rui Ueyama2013-12-111-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is to basically move the functionality to construct Data Directory from IdataPass to WriterPECOFF. Data Directory is a part of the PE/COFF header and contains the addresses of the import tables. We used to represent the link from Data Directory to the import tables as relocation references. The idea behind it is that, because relocation references are processed by the Writer, we wouldn't have to do anything special to fill the addresses of the import tables. I thought that the addresses would be set "automatically". But it turned out that that design made the pass and the writer rather complicated. In order to make relocation references between Data Directory to the import tables, these data structures needed to be represented as Atom. However, because Data Directory is not a section content but a part of the PE/COFF header, it did not fit well as an Atom. So we ended up having complicated code both in IdataPass and the writer. This patch simplifies it. One side effect of this patch is that we now have ".idata.a", ".idata.d" and "idata.t" sections for the import address table, the import directory table, and the import lookup table. The writer looks for the sections by name to find the start addresses of the sections. We probably should have a better way to find a specific atom from the core linking result, but currently using the section name seems to be the easiest way to do that. The Windows loader do not care about the import table's section layout. llvm-svn: 197016
* Add explictly exported atoms and export R_*_COPY'ed atoms.Michael J. Spencer2013-11-081-2/+14
| | | | llvm-svn: 194278
OpenPOWER on IntegriCloud