summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Object
Commit message (Collapse)AuthorAgeFilesLines
* [MIPS][ELF] Use PC-relative relocations in .eh_frame when possibleAlex Richardson2020-01-131-0/+3
| | | | | | | | | | | | | | | | | | | | When compiling position-independent executables, we now use DW_EH_PE_pcrel | DW_EH_PE_sdata4. However, the MIPS ABI does not define a 64-bit PC-relative ELF relocation so we cannot use sdata8 for the large code model case. When using the large code model, we fall back to the previous behaviour of generating absolute relocations. With this change clang-generated .o files can be linked by LLD without having to pass -Wl,-z,notext (which creates text relocations). This is simpler than the approach used by ld.bfd, which rewrites the .eh_frame section to convert absolute relocations into relative references. I saw in D13104 that apparently ld.bfd did not accept pc-relative relocations for MIPS ouput at some point. However, I also checked that recent ld.bfd can process the clang-generated .o files so this no longer seems true. Reviewed By: atanasyan Differential Revision: https://reviews.llvm.org/D72228
* [llvm-readobj] - Remove an excessive helper for printing dynamic tags.Georgii Rymar2019-12-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This removes the `getTypeString` from readeobj source because it almost duplicates the existent method: `ELFFile<ELFT>::getDynamicTagAsString`. Side effect: now it prints "<unknown:>0xHEXVALUE" instead of "(unknown)" for unknown values. llvm-readelf before this patch printed: ``` 0x0000000012345678 (unknown) 0x8765432187654321 0x000000006abcdef0 (unknown) 0x9988776655443322 0x0000000076543210 (unknown) 0x5555666677778888 ``` and now it prints: ``` 0x0000000012345678 (<unknown:>0x12345678) 0x8765432187654321 0x000000006abcdef0 (<unknown:>0x6abcdef0) 0x9988776655443322 0x0000000076543210 (<unknown:>0x76543210) 0x5555666677778888 ``` GNU reaedlf prints different thing: ``` 0x0000000012345678 (<unknown>: 12345678) 0x8765432187654321 0x000000006abcdef0 (Operating System specific: 6abcdef0) 0x9988776655443322 0x0000000076543210 (Processor Specific: 76543210) 0x5555666677778888 ``` I am not sure we want to follow GNU here. Even if we do, it should be separate patch probably. The new output looks better and closer to GNU anyways, and the code is a bit simpler. Differential revision: https://reviews.llvm.org/D71835
* [WebAssembly] Add new `export_name` clang attribute for controlling wasm ↵Sam Clegg2019-12-111-7/+10
| | | | | | | | | | | | | | | | | | | | export names This is equivalent to the existing `import_name` and `import_module` attributes which control the import names in the final wasm binary produced by lld. This maps the existing This attribute currently requires a string rather than using the symbol name for a couple of reasons: 1. Avoid confusion with static and dynamic linking which is based on symbol name. Exporting a function from a wasm module using this directive is orthogonal to both static and dynamic linking. 2. Avoids name mangling. Differential Revision: https://reviews.llvm.org/D70520
* [Object][RISCV] Resolve R_RISCV_32_PCRELLuís Marques2019-11-211-0/+3
| | | | | | | | | | | | | Summary: Add support for resolving `R_RISCV_32_PCREL` relocations. Those aren't actually resolved AFAIK, but support is still needed to avoid llvm-dwarfdump errors. The use of these relocations was introduced in D66419 but the corresponding resolving wasn't added then. The test adds a check that should catch future unresolved relocations. Reviewers: asb, lenary Reviewed By: asb Tags: #llvm Differential Revision: https://reviews.llvm.org/D70204
* [Object][RISCV] Fix R_RISCV_SET6 and R_RISCV_SUB6 relocations resolutionLuís Marques2019-11-211-2/+2
| | | | | | | | | | Summary: These relocations had a suspicious resolution logic, given their name. This patch makes the resolution match the LLD one, which makes more sense. Reviewers: asb, lenary, HsiangKai, jrtc27 Reviewed By: HsiangKai Tags: #llvm Differential Revision: https://reviews.llvm.org/D70396
* [cmake] Explicitly mark libraries defined in lib/ as "Component Libraries"Tom Stellard2019-11-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Most libraries are defined in the lib/ directory but there are also a few libraries defined in tools/ e.g. libLLVM, libLTO. I'm defining "Component Libraries" as libraries defined in lib/ that may be included in libLLVM.so. Explicitly marking the libraries in lib/ as component libraries allows us to remove some fragile checks that attempt to differentiate between lib/ libraries and tools/ libraires: 1. In tools/llvm-shlib, because llvm_map_components_to_libnames(LIB_NAMES "all") returned a list of all libraries defined in the whole project, there was custom code needed to filter out libraries defined in tools/, none of which should be included in libLLVM.so. This code assumed that any library defined as static was from lib/ and everything else should be excluded. With this change, llvm_map_components_to_libnames(LIB_NAMES, "all") only returns libraries that have been added to the LLVM_COMPONENT_LIBS global cmake property, so this custom filtering logic can be removed. Doing this also fixes the build with BUILD_SHARED_LIBS=ON and LLVM_BUILD_LLVM_DYLIB=ON. 2. There was some code in llvm_add_library that assumed that libraries defined in lib/ would not have LLVM_LINK_COMPONENTS or ARG_LINK_COMPONENTS set. This is only true because libraries defined lib lib/ use LLVMBuild.txt and don't set these values. This code has been fixed now to check if the library has been explicitly marked as a component library, which should now make it easier to remove LLVMBuild at some point in the future. I have tested this patch on Windows, MacOS and Linux with release builds and the following combinations of CMake options: - "" (No options) - -DLLVM_BUILD_LLVM_DYLIB=ON - -DLLVM_LINK_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_BUILD_LLVM_DYLIB=ON - -DBUILD_SHARED_LIBS=ON -DLLVM_LINK_LLVM_DYLIB=ON Reviewers: beanz, smeenai, compnerd, phosek Reviewed By: beanz Subscribers: wuzish, jholewinski, arsenm, dschuff, jyknight, dylanmckay, sdardis, nemanjai, jvesely, nhaehnle, mgorny, mehdi_amini, sbc100, jgravelle-google, hiraditya, aheejin, fedor.sergeev, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, MaskRay, zzheng, edward-jones, atanasyan, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, PkmX, jocewei, jsji, dang, Jim, lenary, s.egerton, pzheng, sameer.abuasal, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70179
* The patch is the compiler error specific on the compile error on CMVCdiggerlin2019-11-191-3/+5
| | | | | | | | | | | | | | | | | | | | | | | SUMMARY: CMVC has a compiler error on the const uint64_t OffsetToRaw = is64Bit() ? toSection64(Sec)->FileOffsetToRawData : toSection32(Sec)->FileOffsetToRawData; while gcc compiler do not have the problem. I have to change the code to uint64_t OffsetToRaw; if (is64Bit()) OffsetToRaw = toSection64(Sec)->FileOffsetToRawData; else OffsetToRaw = toSection32(Sec)->FileOffsetToRawData; Reviewers: Sean Fertile Subscribers: rupprecht, seiyai,hiraditya Differential Revision: https://reviews.llvm.org/D70255
* implement printing out raw section data of xcoff objectfile for llvm-objdumpdiggerlin2019-11-191-8/+17
| | | | | | | | | | | SUMMARY: implement printing out raw section data of xcoff objectfile for llvm-objdump and option -D --disassemble-all option for llvm-objdump Reviewers: Sean Fertile Subscribers: rupprecht, seiyai,hiraditya Differential Revision: https://reviews.llvm.org/D70255
* Add operator<< for object::SectionedAddressPavel Labath2019-11-191-0/+7
| | | | | | The main motivation for this is better failure messages in unit tests. Split off from D70394.
* Revert "implement printing out raw section data of xcoff objectfile for ↵Leonard Chan2019-11-181-17/+8
| | | | | | | | llvm-objdump" This reverts commit 8f8a9f3437d4517f674395da30edb59d5514f7bc. Reverting since this patch seems to break a lot of llvm buildbots.
* [macho] Allow CPUSubtype to contribute to architecture identificationDaniel Sanders2019-11-181-2/+6
| | | | | | | | | | | | | | | Summary: Sometimes the CPUSubtype determines the Triple::ArchType that must be used. Add the subtype to the API's to allow targets that need this to correctly identify the contents of the binary. Reviewers: pete Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70345
* implement printing out raw section data of xcoff objectfile for llvm-objdumpdiggerlin2019-11-181-8/+17
| | | | | | | | | | | SUMMARY: implement printing out raw section data of xcoff objectfile for llvm-objdump and option -D --disassemble-all option for llvm-objdump Reviewers: Sean Fertile Subscribers: rupprecht, seiyai,hiraditya Differential Revision: https://reviews.llvm.org/D70255
* Revert "[XCOFF] Fix link errors from explicit template instantiation"Reid Kleckner2019-11-071-4/+0
| | | | | | | | This reverts commit c989993ba1a666f04f7aee7df51d9f4de0588b71. maskray already fixed the explicit instantiation definition in the .cpp file, and these extern template declarations seem to be causing warnings that I don't understand.
* [XCOFF] Fix link errors from explicit template instantiationReid Kleckner2019-11-071-0/+4
| | | | | | | | | | | | | | | | I happen to be using clang-cl+lld-link locally, and I get these link errors: lld-link: error: undefined symbol: public: unsigned short __cdecl llvm::object::XCOFFSectionHeader<struct llvm::object::XCOFFSectionHeader64>::getSectionType(void) const >>> referenced by C:\src\llvm-project\llvm\tools\llvm-readobj\XCOFFDumper.cpp:106 >>> tools\llvm-readobj\CMakeFiles\llvm-readobj.dir\XCOFFDumper.cpp.obj:(public: virtual void __cdecl `anonymous namespace'::XCOFFDumper::printSectionHeaders(void)) I suspect this is because the explicit template instaniation appears before the inline method definitions in the .cpp file, so they aren't available at the point of instantiation. Move the explicit instantiation later. Also, forward declare the explicit instantiation for good measure.
* [XCOFF] Move explicit instantions after member function definitions to fix ↵Fangrui Song2019-11-071-4/+4
| | | | clang builds
* Using crtp to refactor the xcoff section headerdiggerlin2019-11-071-8/+19
| | | | | | | | | | | | | SUMMARY: According to https://reviews.llvm.org/D68575#inline-617586, Create a NFC patch for it. Using crtp to refactor the xcoff section header Move the define of SectionFlagsReservedMask and SectionFlagsTypeMask from XCOFFDumper.cpp to XCOFFObjectFile.h Reviewers: hubert.reinterpretcast,jasonliu Subscribers: rupprecht, seiyai,hiraditya Differential Revision: https://reviews.llvm.org/D69131
* [Mips] Use appropriate private label prefix based on Mips ABIMirko Brkusanin2019-10-231-2/+2
| | | | | | | | | | MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64 regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo we can find out Mips ABI and pick appropriate prefix. Tags: #llvm, #clang, #lldb Differential Revision: https://reviews.llvm.org/D66795
* [llvm/Object] - Make ELFObjectFile::getRelocatedSection return ↵George Rimar2019-10-211-1/+2
| | | | | | | | | | | | | Expected<section_iterator> It returns just a section_iterator currently and have a report_fatal_error call inside. This change adds a way to return errors and handle them on caller sides. The patch also changes/improves current users and adds test cases. Differential revision: https://reviews.llvm.org/D69167 llvm-svn: 375408
* [WebAssembly] Allow multivalue signatures in object filesThomas Lively2019-10-181-6/+3
| | | | | | | | | | | | | | | | | Summary: Also changes the wasm YAML format to reflect the possibility of having multiple return types and to put the returns after the params for consistency with the binary encoding. Reviewers: aheejin, sbc100 Subscribers: dschuff, jgravelle-google, hiraditya, sunfish, arphaman, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D69156 llvm-svn: 375283
* Fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warnings. ↵Simon Pilgrim2019-10-181-1/+1
| | | | | | NFCI. llvm-svn: 375213
* [XCOFF]implement parsing relocation information for 32-bit xcoff object fileDigger Lin2019-10-151-4/+68
| | | | | | | | | | | | | | Summary: Parsing the relocation entry information for 32-bit xcoff object file including deal with the relocation overflow. Reviewers: hubert.reinterpretcast, jasonliu, sfertile, xingxue. Subscribers: hiraditya, rupprecht, seiya Differential Revision: https://reviews.llvm.org/D67008 llvm-svn: 374946
* revert git test commitDigger Lin2019-10-151-1/+1
| | | | llvm-svn: 374898
* a test commit accessDigger Lin2019-10-151-1/+1
| | | | llvm-svn: 374897
* Object/minidump: Add support for the MemoryInfoList streamPavel Labath2019-10-081-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds the definitions of the constants and structures necessary to interpret the MemoryInfoList minidump stream, as well as the object::MinidumpFile interface to access the stream. While the code is fairly simple, there is one important deviation from the other minidump streams, which is worth calling out explicitly. Unlike other "List" streams, the size of the records inside MemoryInfoList stream is not known statically. Instead it is described in the stream header. This makes it impossible to return ArrayRef<MemoryInfo> from the accessor method, as it is done with other streams. Instead, I create an iterator class, which can be parameterized by the runtime size of the structure, and return iterator_range<iterator> instead. Reviewers: amccarth, jhenderson, clayborg Subscribers: JosephTremoulet, zturner, markmentovai, lldb-commits, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68210 llvm-svn: 374051
* ObjectFile makeTriple - silence static analyzer dyn_cast<COFFObjectFile> ↵Simon Pilgrim2019-10-011-1/+1
| | | | | | | | null dereference warning. NFCI. The static analyzer is warning about a potential null dereference, but we should be able to use cast<COFFObjectFile> directly and if not assert will fire for us. llvm-svn: 373324
* [Alignment][NFC] Remove unneeded llvm:: scoping on Align typesGuillaume Chatelet2019-09-271-5/+5
| | | | llvm-svn: 373081
* [NFC] Add { } to silence compiler warning [-Wmissing-braces].Huihui Zhang2019-09-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | /local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Object/MachOObjectFile.cpp:2731:7: warning: suggest braces around initialization of subobject [-Wmissing-braces] "i386", "x86_64", "x86_64h", "armv4t", "arm", "armv5e", ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ { 1 warning generated. /local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp:355:46: warning: suggest braces around initialization of subobject [-Wmissing-braces] return addMappingFromTable<1>(MI, MRI, { 0 }, Table); ^ {} 1 warning generated. /local/mnt/workspace/huihuiz/llvm-comm-git-2/llvm-project/llvm/tools/llvm-objcopy/ELF/Object.cpp:400:57: warning: suggest braces around initialization of subobject [-Wmissing-braces] static constexpr std::array<uint8_t, 4> ZlibGnuMagic = {'Z', 'L', 'I', 'B'}; ^~~~~~~~~~~~~~~~~~ { } 1 warning generated. llvm-svn: 372811
* Support for 64-bit PC-relative relocations for X86_64Artur Pilipenko2019-09-211-0/+2
| | | | | | | | | | | | | | | | | | | | | ELF files generated for X86_64 targets may contain 64-bit PC-relative relocations. For instance, an exception handler table entry contains the start of exception-throwing frame relative to the start of exception handler. As these two labels belong to different sections, their difference and so the relocation is 64-bit. An attempt to parse such file, i.e. in DWARFContext::create, results in "failed to compute relocation" error. This fix adds support for such relocations to RelocationResolver.cpp. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D67779 Patch by Oleg Pliss (Oleg.Pliss@azul.com) llvm-svn: 372447
* [TextAPI] Arch&Platform to TargetCyndy Ishida2019-09-201-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: This is a patch for updating TextAPI/Macho to read in targets as opposed to arch/platform. This is because in previous versions tbd files only supported a single platform but that is no longer the case, so, now its tracked by unique triples. This precedes a seperate patch that will add the TBD-v4 format Reviewers: ributzka, steven_wu, plotfi, compnerd, smeenai Reviewed By: ributzka Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67527 llvm-svn: 372396
* [Object] Uncapitalize an error messageFangrui Song2019-09-201-1/+1
| | | | | | Test case will be added by my next commit. llvm-svn: 372369
* [Object] Extend MachOUniversalBinary::getObjectForArchAlexander Shaposhnikov2019-09-192-5/+20
| | | | | | | | | | | | Make the method MachOUniversalBinary::getObjectForArch return MachOUniversalBinary::ObjectForArch and add helper methods MachOUniversalBinary::getMachOObjectForArch, MachOUniversalBinary::getArchiveForArch for those who explicitly expect to get a MachOObjectFile or an Archive. Differential revision: https://reviews.llvm.org/D67700 Test plan: make check-all llvm-svn: 372278
* [ARM] VFPv2 only supports 16 D registers.Eli Friedman2019-09-171-1/+1
| | | | | | | | | | | | | | | | | | | | r361845 changed the way we handle "D16" vs. "D32" targets; there used to be a negative "d16" which removed instructions from the instruction set, and now there's a "d32" feature which adds instructions to the instruction set. This is good, but there was an oversight in the implementation: the behavior of VFPv2 was changed. In particular, the "vfp2" feature was changed to imply "d32". This is wrong: VFPv2 only supports 16 D registers. In practice, this means if you specify -mfpu=vfpv2, the compiler will generate illegal instructions. This patch gets rid of "vfp2d16" and "vfp2d16sp", and fixes "vfp2" and "vfp2sp" so they don't imply "d32". Differential Revision: https://reviews.llvm.org/D67375 llvm-svn: 372186
* [Alignment] Move OffsetToAlignment to Alignment.hGuillaume Chatelet2019-09-121-6/+8
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, JDevlieghere, alexshap, rupprecht, jhenderson Subscribers: sdardis, nemanjai, hiraditya, kbarton, jakehehrlich, jrtc27, MaskRay, atanasyan, jsji, seiya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67499 llvm-svn: 371742
* Revert [llvm-nm] Add tapi file supportCyndy Ishida2019-09-111-1/+1
| | | | | | This reverts r371576 (git commit f88f46358dbffa20af3b054a9346e5154789d50f) llvm-svn: 371676
* [llvm-nm] Add tapi file supportCyndy Ishida2019-09-111-1/+1
| | | | | | | | | | | | | | | | | | Summary: This commit is the final one for adding tapi support to the llvm-nm implementation. This commit also has accompanying tests the additions to lib/Object Reviewers: ributzka, steven_wu Reviewed By: ributzka Subscribers: hiraditya, plotfi, dexonsmith, rupprecht, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66160 llvm-svn: 371576
* [Object] Implement relocation resolver for COFF ARM/ARM64Martin Storsjo2019-09-101-2/+53
| | | | | | | | | | Adding testscases for this via llvm-dwarfdump. Also add testcases for the existing resolver support for X86. Differential Revision: https://reviews.llvm.org/D67340 llvm-svn: 371515
* [llvm-readobj][yaml2obj] Support SHT_LLVM_SYMPART, SHT_LLVM_PART_EHDR and ↵Fangrui Song2019-09-061-0/+2
| | | | | | | | | | | | | | | | | | | | | SHT_LLVM_PART_PHDR See http://lists.llvm.org/pipermail/llvm-dev/2019-February/130583.html and D60242 for the lld partition feature. This patch: * Teaches yaml2obj to parse the 3 section types. * Teaches llvm-readobj/llvm-readelf to dump the 3 section types. There is no test for SHT_LLVM_DEPENDENT_LIBRARIES in llvm-readobj. Add it as well. Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D67228 llvm-svn: 371157
* [LLD] [COFF] Implement MinGW default manifest handlingMartin Storsjo2019-09-041-5/+95
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In mingw environments, resources are normally compiled to resource object files directly, instead of letting the linker convert them to COFF format. Since some time, GCC supports the notion of a default manifest object. When invoking the linker, GCC looks for the default manifest object file, and if found in the expected path, it is added to linker commands. The default manifest is one that indicates support for the latest known versions of windows, to implicitly unlock the modern behaviours of certain APIs. Not all mingw/gcc distributions include this file, but e.g. in msys2, the default manifest object is distributed in a separate package (which can be but might not always be installed). This means that even if user projects only use one single resource object file, the linker can end up with two resource object files, and thus needs to support merging them. The default manifest has a language id of zero, and GNU ld has got logic for dropping a manifest with a zero language id, if there's another manifest present with a nonzero language id. If there are multiple manifests with a nonzero language id, the merging process errors out. Differential Revision: https://reviews.llvm.org/D66825 llvm-svn: 370974
* Recommit r370661 "[llvm-nm] - Add a test case for case when we dump a symbol ↵George Rimar2019-09-021-1/+3
| | | | | | | | | | | | | | | | | | | that belongs to a section with a broken sh_name." Fix: add a 'consumeError()' call to ObjectFile.cpp. This error was never checked. Original commit message: It adds a test case for a problem fixed by D66976 <https://reviews.llvm.org/D66976>. It was introduced by me in D66089 <https://reviews.llvm.org/D66089>. The error reported was never consumed because of a wrong variable name used, so it could fail when LLVM_ENABLE_ABI_BREAKING_CHECKS is used. Differential revision: https://reviews.llvm.org/D67002 llvm-svn: 370669
* [LLD] [COFF] Support merging resource object filesMartin Storsjo2019-08-301-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | Extend WindowsResourceParser to support using a ResourceSectionRef for loading resources from an object file. Only allow merging resource object files in mingw mode; keep the existing error on multiple resource objects in link mode. If there only is one resource object file and no .res resources, don't parse and recreate the .rsrc section, but just link it in without inspecting it. This allows users to produce any .rsrc section (outside of what the parser supports), just like before. (I don't have a specific need for this, but it reduces the risk of this new feature.) Separate out the .rsrc section chunks in InputFiles.cpp, and only include them in the list of section chunks to link if we've determined that there only was one single resource object. (We need to keep other chunks from those object files, as they can legitimately contain other sections as well, in addition to .rsrc section chunks.) Differential Revision: https://reviews.llvm.org/D66824 llvm-svn: 370436
* [WindowsResource] Remove use of global variables in WindowsResourceParserMartin Storsjo2019-08-301-58/+45
| | | | | | | | | | | | | | | | Instead of updating a global variable counter for the next index of strings and data blobs, pass along a reference to actual data/string vectors and let the TreeNode insertion methods add their data/strings to the vectors when a new entry is needed. Additionally, if the resource tree had duplicates, that were ignored with -force:multipleres in lld, we no longer store all versions of the duplicated resource data, now we only keep the one that actually ends up referenced. Differential Revision: https://reviews.llvm.org/D66823 llvm-svn: 370435
* [WindowsResource] Avoid duplicating the input filenames for each resource. NFC.Martin Storsjo2019-08-301-4/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D66821 llvm-svn: 370434
* [COFF] Add a ResourceSectionRef method for getting resource contentsMartin Storsjo2019-08-301-0/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows llvm-readobj to print the contents of each resource when printing resources from an object file or executable, like it already does for plain .res files. This requires providing the whole COFFObjectFile to ResourceSectionRef. This supports both object files and executables. For executables, the DataRVA field is used as is to look up the right section. For object files, ideally we would need to complete linking of them and fix up all relocations to know what the DataRVA field would end up being. In practice, the only thing that makes sense for an RVA field is an ADDR32NB relocation. Thus, find a relocation pointing at this field, verify that it has the expected type, locate the symbol it points at, look up the section the symbol points at, and read from the right offset in that section. This works both for GNU windres object files (which use one single .rsrc section, with all relocations against the base of the .rsrc section, with the original value of the DataRVA field being the offset of the data from the beginning of the .rsrc section) and cvtres object files (with two separate .rsrc$01 and .rsrc$02 sections, and one symbol per data entry, with the original pre-relocated DataRVA field being set to zero). Differential Revision: https://reviews.llvm.org/D66820 llvm-svn: 370433
* [COFF] Add a ResourceSectionRef method for getting the data entry, print it ↵Martin Storsjo2019-08-291-0/+18
| | | | | | | | in llvm-readobj Differential Revision: https://reviews.llvm.org/D66819 llvm-svn: 370311
* [COFF] Add a bounds checking helper for iterating a coff_resource_dir_tableMartin Storsjo2019-08-291-0/+22
| | | | | | | | | | Instead of blindly incrementing pointers in llvm-readobj, use this helper, which does bounds checking against the available section data. Differential Revision: https://reviews.llvm.org/D66818 llvm-svn: 370310
* [COFF] Fix error handling in ResourceSectionRefMartin Storsjo2019-08-291-3/+6
| | | | | | | | | | | Previously, the expression (Reader.readFoo()) was expanded twice, triggering asserts as one of the Error types ends up not checked (and as it was expanded twice, the method would end up called twice if it failed first). Differential Revision: https://reviews.llvm.org/D66817 llvm-svn: 370309
* [llvm-objdump] Add the missing ARMv8 subarch detectionYi Kong2019-08-281-0/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D66849 llvm-svn: 370163
* [XCOFF][AIX] Generate symbol table entries with llvm-readobjJason Liu2019-08-271-20/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch implements main entry and auxiliary entries of symbol table generation for llvm-readobj on AIX. The source code of aix_xcoff_xlc_test8.o (compile with xlc) is: -bash-4.2$ cat test8.c extern int i; extern int TestforXcoff; extern int fun(int i); static int static_i; char* p="abcd"; int fun1(int j) { static_i++; j++; j=j+*p; return j; } int main() { i++; fun(i); return fun1(i); } Patch provided by DiggerLin Differential Revision: https://reviews.llvm.org/D65240 llvm-svn: 370097
* [Object] FIX: update PlatformKind name in TapiFileCyndy Ishida2019-08-211-2/+2
| | | | | | | Buildbots that use GCC failed to compile because overwritten namespace with variable name llvm-svn: 369602
* [Object] Add tapi files to objectCyndy Ishida2019-08-215-3/+163
| | | | | | | | | | | | | | | | | | | | | Summary: The intention for this is to allow reading and printing symbols out from llvm-nm. Tapi file, and Tapi universal follow a similiar format to their respective MachO Object format. The tests are dependent on llvm-nm processing tbd files which is why its in D66160 Reviewers: ributzka, steven_wu, lhames Reviewed By: ributzka, lhames Subscribers: mgorny, hiraditya, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66159 llvm-svn: 369600
OpenPOWER on IntegriCloud