summaryrefslogtreecommitdiffstats
path: root/llvm/tools/obj2yaml/elf2yaml.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [yaml2obj/obj2yaml] - Add support for SHT_RELR sections.Georgii Rymar2020-01-151-0/+33
| | | | | | | | | | | | | | | | | | | Note: this is a reland with a trivial 2 lines fix in ELFState<ELFT>::writeSectionContent. It adds a check similar to ones we already have for other sections to fix the case revealed by bots, like http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/60744. The encoded sequence of Elf*_Relr entries in a SHT_RELR section looks like [ AAAAAAAA BBBBBBB1 BBBBBBB1 ... AAAAAAAA BBBBBB1 ... ] i.e. start with an address, followed by any number of bitmaps. The address entry encodes 1 relocation. The subsequent bitmap entries encode up to 63(31) relocations each, at subsequent offsets following the last address entry. More information is here: https://github.com/llvm-mirror/llvm/blob/master/lib/Object/ELF.cpp#L272 This patch adds a support for these sections. Differential revision: https://reviews.llvm.org/D71872
* Revert "[yaml2obj/obj2yaml] - Add support for SHT_RELR sections."Georgii Rymar2020-01-151-33/+0
| | | | | | This reverts commit 46d11e30ee807accefd14e0b7f306647963a39b5. It broke bots. E.g. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/60744
* [yaml2obj/obj2yaml] - Add support for SHT_RELR sections.Georgii Rymar2020-01-151-0/+33
| | | | | | | | | | | | | | | The encoded sequence of Elf*_Relr entries in a SHT_RELR section looks like [ AAAAAAAA BBBBBBB1 BBBBBBB1 ... AAAAAAAA BBBBBB1 ... ] i.e. start with an address, followed by any number of bitmaps. The address entry encodes 1 relocation. The subsequent bitmap entries encode up to 63(31) relocations each, at subsequent offsets following the last address entry. More information is here: https://github.com/llvm-mirror/llvm/blob/master/lib/Object/ELF.cpp#L272 This patch adds a support for these sections. Differential revision: https://reviews.llvm.org/D71872
* [yaml2obj] - Make DynamicSymbols to be Optional<> too.Georgii Rymar2019-12-041-2/+4
| | | | | | | | | | | | | | | | | | We already have Symbols property to list regular symbols and it is currently Optional<>. This patch makes DynamicSymbols to be optional too. With this there is no need to define a dummy symbol anymore to trigger creation of the .dynsym and it is now possible to define an empty .dynsym using just the following line: DynamicSymbols: [] (it is important to have when you do not want to have dynamic symbols, but want to have a .dynsym) Now the code is consistent and it helped to fix a bug: previously we did not report an error when both Content/Size and an empty Symbols/DynamicSymbols list were specified. Differential revision: https://reviews.llvm.org/D70956
* [yaml2obj] - Add a way to describe content of the SHT_GNU_verneed section ↵Georgii Rymar2019-11-291-1/+3
| | | | | | | | | with "Content". There is no way to set raw content for SHT_GNU_verneed section. This patch implements it. Differential revision: https://reviews.llvm.org/D70816
* [yaml2obj] - Teach tool to describe SHT_GNU_verdef section with a "Content" ↵Georgii Rymar2019-11-261-1/+3
| | | | | | | | | property. There is no way to set raw content for SHT_GNU_verdef section. This patch implements it. Differential revision: https://reviews.llvm.org/D70710
* [yaml2obj/obj2yaml] - Add support for SHT_LLVM_DEPENDENT_LIBRARIES sections.Georgii Rymar2019-11-251-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | This section contains strings specifying libraries to be added to the link by the linker. The strings are encoded as standard null-terminated UTF-8 strings. This patch adds a way to describe and dump SHT_LLVM_DEPENDENT_LIBRARIES sections. I introduced a new YAMLFlowString type here. That used to teach obj2yaml to dump them like: ``` Libraries: [ foo, bar ] ``` instead of the following (if StringRef would be used): ``` Libraries: - foo - bar ``` Differential revision: https://reviews.llvm.org/D70598
* [yaml2obj/obj2yaml] - Add support for SHT_LLVM_LINKER_OPTIONS sections.Georgii Rymar2019-11-121-0/+41
| | | | | | | SHT_LLVM_LINKER_OPTIONS section contains pairs of null-terminated strings. This patch adds support for them. Differential revision: https://reviews.llvm.org/D69895
* [yaml2obj] - Add a way to describe the custom data that is not part of an ↵Georgii Rymar2019-11-111-18/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | output section. Currently there is no way to describe the data that is not a part of an output section. It can be a data used to align sections or to fill the gaps with something, or another kind of custom data. In this patch I suggest a way to describe it. It looks like that: ``` Sections: - Type: CustomFiller Pattern: "CCDD" Size: 4 - Name: .bar Type: SHT_PROGBITS Content: "FF" ``` I.e. I've added a kind of synthetic section with a synthetic type "CustomFiller". In the code it is called a "SyntheticFiller", which is "a synthetic section which might be used to write the custom data around regular output sections. It does not present in the sections header table, but it might affect the output file size and program headers produced. Think about it as about piece of data." `SyntheticFiller` currently has a `Pattern` field and a `Size` field + an optional `Name`. When written, `Size` of bytes in the output will be filled with a `Pattern`. It is possible to reference a named filler it by name from the program headers description, just like any other normal section. Differential revision: https://reviews.llvm.org/D69709
* [yaml2obj/obj2yaml] - Add support for SHT_GNU_HASH section.georgerim2019-10-311-0/+59
| | | | | | | This adds parsing and dumping support for GNU hash sections. They are described nicely here: https://blogs.oracle.com/solaris/gnu-hash-elf-sections-v2 Differential revision: https://reviews.llvm.org/D69399
* [yaml2obj, obj2yaml] - Add support for SHT_NOTE sections.georgerim2019-10-251-0/+46
| | | | | | | | | | | | | | | | | | | | | SHT_NOTE is the section that consists of namesz, descsz, type, name + padding, desc + padding data. This patch teaches yaml2obj, obj2yaml to dump and parse them. This patch implements the section how it is described here: https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-18048.html Which says: "For 64–bit objects and 32–bit objects, each entry is an array of 4-byte words in the format of the target processor" The official specification is different http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section And says: "n 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each entry is an array of 8-byte words in the format of the target processor. In 32-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS32), each entry is an array of 4-byte words in the format of the target processor" Since LLVM uses the first, 32-bit way, this patch follows it. Differential revision: https://reviews.llvm.org/D68983
* [obj2yaml] - Better dumping for relocations without symbols associated.georgerim2019-10-251-13/+11
| | | | | | | | | This just reorders the code and removes an assignment of an empty string for the case when a relocation has no symbol associated. With this our output becomes cleaner and shorter. Differential revision: https://reviews.llvm.org/D69255
* [yaml2obj][obj2yaml] - Do not create a symbol table by default.George Rimar2019-10-201-2/+6
| | | | | | | | | | | | | | | | | | This patch tries to resolve problems faced in D68943 and uses some of the code written by Konrad Wilhelm Kleine in that patch. Previously, yaml2obj tool always created a .symtab section. This patch changes that. With it we only create it when have a "Symbols:" tag in the YAML document or when we need to create it because it is used by another section(s). obj2yaml follows the new behavior and does not print "Symbols:" anymore when there is no symbol table. Differential revision: https://reviews.llvm.org/D69041 llvm-svn: 375361
* Recommit r373598 "[yaml2obj/obj2yaml] - Add support for SHT_LLVM_ADDRSIG ↵George Rimar2019-10-031-10/+65
| | | | | | | | | | | | | | | | | sections." Fix: call `consumeError()` for a case missed. Original commit message: SHT_LLVM_ADDRSIG is described here: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table This patch teaches tools to dump them and to parse the YAML declarations of such sections. Differential revision: https://reviews.llvm.org/D68333 llvm-svn: 373606
* Revert r373598 "[yaml2obj/obj2yaml] - Add support for SHT_LLVM_ADDRSIG ↵George Rimar2019-10-031-64/+10
| | | | | | | | | sections." It broke BB: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/18655/steps/test/logs/stdio llvm-svn: 373599
* [yaml2obj/obj2yaml] - Add support for SHT_LLVM_ADDRSIG sections.George Rimar2019-10-031-10/+64
| | | | | | | | | | | SHT_LLVM_ADDRSIG is described here: https://llvm.org/docs/Extensions.html#sht-llvm-addrsig-section-address-significance-table This patch teaches tools to dump them and to parse the YAML declarations of such sections. Differential revision: https://reviews.llvm.org/D68333 llvm-svn: 373598
* [obj2yaml] - Fix BB after r373315.George Rimar2019-10-011-4/+6
| | | | | | | The success return value for data extractor's cursor should also be checked. llvm-svn: 373319
* [yaml2obj/obj2yaml] - Add support for SHT_HASH sections.George Rimar2019-10-011-0/+47
| | | | | | | | | | | | | | | SHT_HASH specification is: http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#hash In short the format is the following: it has 2 uint32 fields in its header: nbucket and nchain followed by (nbucket + nchain) uint32 values. This patch allows dumping and parsing such sections. Differential revision: https://reviews.llvm.org/D68085 llvm-svn: 373315
* [yaml2obj/obj2yaml] - Add support for .stack_sizes sections.George Rimar2019-09-241-0/+61
| | | | | | | | | | | .stack_sizes is a SHT_PROGBITS section that contains pairs of <address (4/8 bytes), stack size (uleb128)>. This patch teach tools to parse and dump it. Differential revision: https://reviews.llvm.org/D67757 llvm-svn: 372762
* [yaml2obj] Rename SHOffset (e_shoff) field to SHOff. NFCFangrui Song2019-09-061-1/+1
| | | | | | | | | | | `struct Elf*_Shdr` has a field `sh_offset`, named `ShOffset` in llvm::ELFYAML::Section. Rename SHOffset (e_shoff) to SHOff to prevent confusion. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D67254 llvm-svn: 371185
* [llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-151-11/+11
| | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
* [yaml2obj/obj2yaml] - Add a basic support for extended section indexes.George Rimar2019-08-081-13/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | In some cases a symbol might have section index == SHN_XINDEX. This is an escape value indicating that the actual section header index is too large to fit in the containing field. Then the SHT_SYMTAB_SHNDX section is used. It contains the 32bit values that stores section indexes. ELF gABI says that there can be multiple SHT_SYMTAB_SHNDX sections, i.e. for example one for .symtab and one for .dynsym (1) https://groups.google.com/forum/#!topic/generic-abi/-XJAV5d8PRg (2) DT_SYMTAB_SHNDX: http://www.sco.com/developers/gabi/latest/ch5.dynamic.html In this patch I am only supporting a single SHT_SYMTAB_SHNDX associated with a .symtab. This is a more or less common case which is used a few tests I saw in LLVM. I decided not to create the SHT_SYMTAB_SHNDX section as "implicit", but implement is like a kind of regular section for now. i.e. tools do not recreate this section or its content, like they do for symbol table sections, for example. That should allow to write all kind of possible broken test cases for our needs and keep the output closer to requested. Differential revision: https://reviews.llvm.org/D65446 llvm-svn: 368272
* [obj2yaml] - Teach tool to dump SHT_NULL sections.George Rimar2019-08-051-7/+24
| | | | | | | | | | | Recently an advanced support of SHT_NULL sections was implemented in yaml2obj. This patch adds a corresponding support to obj2yaml. Differential revision: https://reviews.llvm.org/D65215 llvm-svn: 367852
* [obj2yaml] - Report a error when unable to resolve a sh_link reference properly.George Rimar2019-07-291-2/+6
| | | | | | | | | Because of a bug we did not report a error in the case shown in the test. With this patch we do. Differential revision: https://reviews.llvm.org/D65214 llvm-svn: 367203
* Recommit r366052 "[obj2yaml] - Rework tool's error reporting logic for ELF ↵George Rimar2019-07-151-162/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | target." No changes, LLD code was updated in r366057. Original commit message: ELF.h contains two getSymbol methods which seems to be used only from obj2yaml. One of these methods calls another, which in turn contains untested error message which doesn't provide enough information. Problem is that after improving only just that message, obj2yaml will not show it, ("Error reading file: yaml: Invalid data was encountered while parsing the file" message will be shown instead), because internal errors handling of tool is based on ErrorOr<> class which stores a error code and as a result can only show a predefined error string, what actually isn't very useful. In this patch, I rework obj2yaml's error reporting system for ELF targets to use Error Expected<> classes. Also, I improve the error message produced by getSymbol for demonstration of the new functionality. Differential revision: https://reviews.llvm.org/D64631 llvm-svn: 366058
* Revert r366052 "[obj2yaml] - Rework tool's error reporting logic for ELF ↵George Rimar2019-07-151-157/+162
| | | | | | | | | target." Seems it broke LLD: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/48434 llvm-svn: 366053
* [obj2yaml] - Rework tool's error reporting logic for ELF target.George Rimar2019-07-151-162/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | ELF.h contains two getSymbol methods which seems to be used only from obj2yaml. One of these methods calls another, which in turn contains untested error message which doesn't provide enough information. Problem is that after improving only just that message, obj2yaml will not show it, ("Error reading file: yaml: Invalid data was encountered while parsing the file" message will be shown instead), because internal errors handling of tool is based on ErrorOr<> class which stores a error code and as a result can only show a predefined error string, what actually isn't very useful. In this patch, I rework obj2yaml's error reporting system for ELF targets to use Error Expected<> classes. Also, I improve the error message produced by getSymbol for demonstration of the new functionality. Differential revision: https://reviews.llvm.org/D64631 llvm-svn: 366052
* [yaml2obj] - Allow overriding sh_offset field from the YAML.George Rimar2019-07-021-0/+2
| | | | | | | | | | | Some of our test cases are using objects which has sections with a broken sh_offset field. There was no way to set it from YAML until this patch. Differential revision: https://reviews.llvm.org/D63879 llvm-svn: 364898
* [yaml2obj] - Allow overriding e_shentsize, e_shoff, e_shnum and e_shstrndx ↵George Rimar2019-06-271-1/+3
| | | | | | | | | | | | fields in the YAML. This allows setting different values for e_shentsize, e_shoff, e_shnum and e_shstrndx fields and is useful for producing broken inputs for various test cases. Differential revision: https://reviews.llvm.org/D63771 llvm-svn: 364517
* [yaml2obj/obj2yaml] - Allow having the symbols and sections with duplicated ↵George Rimar2019-06-251-28/+58
| | | | | | | | | | | | names. The patch teaches yaml2obj/obj2yaml to support parsing/dumping the sections and symbols with the same name. A special suffix is added to a name to make it unique. Differential revision: https://reviews.llvm.org/D63596 llvm-svn: 364282
* [yaml2obj/obj2yaml] - Make RawContentSection::Info Optional<>George Rimar2019-06-191-1/+2
| | | | | | | | This allows to customize this field for "implicit" sections properly. Differential revision: https://reviews.llvm.org/D63487 llvm-svn: 363777
* [yaml2obj] - Allow setting cutom Flags for implicit sections.George Rimar2019-06-141-1/+2
| | | | | | | | | With this patch we get ability to set any flags we want for implicit sections defined in YAML. Differential revision: https://reviews.llvm.org/D63136 llvm-svn: 363367
* [yaml2obj/obj2yaml] - Make RawContentSection::Content and ↵George Rimar2019-06-101-3/+3
| | | | | | | | | | | | | | | | RawContentSection::Size optional This is a follow-up for D62809. Content and Size fields should be optional as was discussed in comments of the D62809's thread. With that, we can describe a specific string table and symbol table sections in a more correct way and also show appropriate errors. The patch adds lots of test cases where the behavior is described in details. Differential revision: https://reviews.llvm.org/D62957 llvm-svn: 362931
* [obj2yamp] - Simplify and cleanup the code in ELFDumper<ELFT>::dumpGroup a ↵George Rimar2019-04-241-27/+25
| | | | | | | | | | bit. NFC. This makes the variables naming to match LLVM style, simplifies the code used to extract the group members, simplifies the loop and reorders the code around a bit. llvm-svn: 359101
* [yaml2obj][obj2yaml] - Change how symbol's binding is descibed when ↵George Rimar2019-04-031-27/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parsing/dumping. Currently, YAML has the following syntax for describing the symbols: Symbols: Local: LocalSymbol1: ... LocalSymbol2: ... ... Global: GlobalSymbol1: ... Weak: ... GNUUnique: I.e. symbols are grouped by their bindings. That is not very convenient, because: It does not allow to set a custom binding, what can be useful for producing broken/special outputs for test cases. Adding a new binding would require to change a syntax (what we observed when added GNUUnique recently). It does not allow to change the order of the symbols in .symtab/.dynsym, i.e. currently all Local symbols are placed first, then Global, Weak and GNUUnique are following, but we are not able to change the order. It is not consistent. Binding is just one of the properties of the symbol, we do not group them by other properties. It makes the code more complex that it can be. This patch shows it can be simplified with the change performed. The patch changes the syntax to just: Symbols: Symbol1: ... Symbol2: ... ... With that, we are able to work with the binding field just like with any other symbol property. Differential revision: https://reviews.llvm.org/D60122 llvm-svn: 357595
* [yaml2obj][obj2yaml] - Teach yaml2obj/obj2yaml tools about STB_GNU_UNIQUE ↵George Rimar2019-03-281-4/+6
| | | | | | | | | | | | | symbols. yaml2obj/obj2yaml does not support the symbols with STB_GNU_UNIQUE yet. Currently, obj2yaml fails with llvm_unreachable when met such a symbol. I faced it when investigated the https://bugs.llvm.org/show_bug.cgi?id=41196. Differential revision: https://reviews.llvm.org/D59875 llvm-svn: 357158
* [yaml2obj] - Allow setting custom sh_info for RawContentSection sections.George Rimar2019-03-011-0/+1
| | | | | | | | | | | This is for tweaking SHT_SYMTAB sections. Their sh_info contains the (number of symbols + 1) usually. But for creating invalid inputs for test cases it would be convenient to allow explicitly override this field from YAML. Differential revision: https://reviews.llvm.org/D58779 llvm-svn: 355193
* [obj2yaml] - Do not miss section index for special symbols.George Rimar2019-02-221-0/+7
| | | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40786 ("obj2yaml symbol output missing section index for SHN_ABS and SHN_COMMON symbols") Since SHN_ABS and SHN_COMMON symbols are special, we should preserve the st_shndx for them. The patch does this for them and the other special symbols. The test case is based on the test provided by James Henderson at the bug page! Differential revision: https://reviews.llvm.org/D58498 llvm-svn: 354661
* [yaml2obj][obj2yaml] - Support SHT_GNU_verdef (.gnu.version_d) section.George Rimar2019-02-211-0/+58
| | | | | | | | | | This patch adds support for parsing/dumping the .gnu.version section. Description of the section is: https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/symverdefs.html Differential revision: https://reviews.llvm.org/D58437 llvm-svn: 354574
* [yaml2obj][obj2yaml] - Support SHT_GNU_versym (.gnu.version) section.George Rimar2019-02-191-0/+26
| | | | | | | | | This patch adds support for parsing dumping the .gnu.version section. Description of the section is: https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/symversion.html#SYMVERTBL Differential revision: https://reviews.llvm.org/D58280 llvm-svn: 354338
* Recommit r354328, r354329 "[obj2yaml][yaml2obj] - Add support of ↵George Rimar2019-02-191-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | parsing/dumping of the .gnu.version_r section." Fix: Replace assert(!IO.getContext() && "The IO context is initialized already"); with assert(IO.getContext() && "The IO context is not initialized"); (this was introduced in r354329, where I tried to quickfix the darwin BB and seems copypasted the assert from the wrong place). Original commit message: The section is described here: https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/symverrqmts.html Patch just teaches obj2yaml/yaml2obj to dump and parse such sections. We did the finalization of string tables very late, and I had to move the logic to make it a bit earlier. That was needed in this patch since .gnu.version_r adds strings to .dynstr. This might also be useful for implementing other special sections. Everything else changed in this patch seems to be straightforward. Differential revision: https://reviews.llvm.org/D58119 llvm-svn: 354335
* Revert r354328, r354329 "[obj2yaml][yaml2obj] - Add support of ↵George Rimar2019-02-191-65/+0
| | | | | | | | | parsing/dumping of the .gnu.version_r section." Something went wrong. Bots are unhappy: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/44113/steps/test/logs/stdio llvm-svn: 354332
* [obj2yaml][yaml2obj] - Add support of parsing/dumping of the .gnu.version_r ↵George Rimar2019-02-191-0/+65
| | | | | | | | | | | | | | | | | | | | section. The section is described here: https://refspecs.linuxfoundation.org/LSB_1.3.0/gLSB/gLSB/symverrqmts.html Patch just teaches obj2yaml/yaml2obj to dump and parse such sections. We did the finalization of string tables very late, and I had to move the logic to make it a bit earlier. That was needed in this patch since .gnu.version_r adds strings to .dynstr. This might also be useful for implementing other special sections. Everything else changed in this patch seems to be straightforward. Differential revision: https://reviews.llvm.org/D58119 llvm-svn: 354328
* [yaml2obj/obj2yaml] - Move `Info` field out from `Section` class.George Rimar2019-02-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ELFYAML.h contains a `Section` class which is a base for a few other sections classes that are used for mapping different section types. `Section` has a `StringRef Info` field used for storing sh_info. At the same time, sh_info has very different meanings for sections and cannot be processed in a similar way generally, for example ELFDumper does not handle it in `dumpCommonSection` but do that in `dumpGroup` and `dumpCommonRelocationSection` respectively. At this moment, we have and handle it as a string, because that was possible for the current use case. But also it can simply be a number: For SHT_GNU_verdef is "The number of version definitions within the section." The patch moves `Info` field out to be able to have it as a number. With that change, each class will be able to decide what type and purpose of the sh_info field it wants to use. I also had to edit 2 test cases. This is because patch fixes a bug. Previously we accepted yaml files with Info fields for all sections (for example, for SHT_DYNSYM too). But we do not handle it and the resulting objects had zero sh_info fields set for such sections. Now it is accepted only for sections that supports it. Differential revision: https://reviews.llvm.org/D58054 llvm-svn: 353810
* [yaml2obj][obj2yaml] - Add support for dumping/parsing .dynamic sections.George Rimar2019-02-091-1/+27
| | | | | | | | | This teaches the tools to parse and dump the .dynamic section and its dynamic tags. Differential revision: https://reviews.llvm.org/D57691 llvm-svn: 353606
* [obj2yaml] - Merge dumpRelSection and dumpRelaSection. NFC.George Rimar2019-02-011-49/+25
| | | | | | | | These methods are very similar, patch merge them into one. Differential revision: https://reviews.llvm.org/D57461 llvm-svn: 352840
* [obj2yaml] - Dump the sh_entsize section field.George Rimar2019-01-281-0/+2
| | | | | | | | | | | | I faced with the fact that obj2yaml does not dump the sh_entsize field. A problem arose when I tried to dump ELF versioning sections. This is close to what D50235 did, but D50235 did the change for yaml2obj, and now I had to do the same for obj2yaml. Differential revision: https://reviews.llvm.org/D57229 llvm-svn: 352373
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [yaml2obj/obj2yaml] - Support dumping/parsing ABI version.George Rimar2018-12-201-0/+1
| | | | | | | | | | | These tools were assuming ABI version is 0, that is not always true. Patch teaches them to work with that field. Differential revision: https://reviews.llvm.org/D55884 llvm-svn: 349737
* Instead of ELFFile<ELFT>::Type, use ELFT::Type. NFC.Rui Ueyama2018-01-121-4/+4
| | | | llvm-svn: 322346
OpenPOWER on IntegriCloud