bcm5719-llvm/llvm/lib/Object, branch meklort-10.0.0

[MIPS][ELF] Use PC-relative relocations in .eh_frame when possible

2020-01-13T14:14:03+00:00

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.

2019-12-24T08:55:45+00:00

This removes the `getTypeString` from readeobj source because it almost duplicates the existent method: `ELFFile::getDynamicTagAsString`. Side effect: now it prints "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 (0x12345678) 0x8765432187654321 0x000000006abcdef0 (0x6abcdef0) 0x9988776655443322 0x0000000076543210 (0x76543210) 0x5555666677778888 ``` GNU reaedlf prints different thing: ``` 0x0000000012345678 (: 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 export names

2019-12-11T19:54:57+00:00

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_PCREL

2019-11-21T23:34:05+00:00

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 resolution

2019-11-21T22:54:10+00:00

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"

2019-11-21T18:48:08+00:00

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 CMVC

2019-11-19T20:17:56+00:00

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-objdump

2019-11-19T18:31:00+00:00

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::SectionedAddress

2019-11-19T09:34:30+00:00

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 llvm-objdump"

2019-11-19T04:05:57+00:00

This reverts commit 8f8a9f3437d4517f674395da30edb59d5514f7bc. Reverting since this patch seems to break a lot of llvm buildbots.