summaryrefslogtreecommitdiffstats
path: root/lld/test
Commit message (Collapse)AuthorAgeFilesLines
* Fix alignment of thunks for ARM/ARM64Martin Storsjö2020-06-171-9/+11
| | | | | | | | | | | | | | The alignment of ARM64 range extension thunks was fixed in 7c816492197a, but ARM range extension thunks, and import and delay import thunks also need aligning (like all code on ARM platforms). I'm adding a test for alignment of ARM64 import thunks - not specifically adding tests for misalignment of all of them though. Differential Revision: https://reviews.llvm.org/D77796 (cherry picked from commit 12c9e2f1110a4fc73562214cf5dd0194b31e87cf)
* [ELF] Don't cause assertion failure if --dynamic-list or --version-script ↵Fangrui Song2020-06-162-0/+9
| | | | | | | | | takes an empty file Fixes PR46184 Report line 1 of the last memory buffer. (cherry picked from commit ac6abc99e2794e4674a8498f817fda19b176bbfe)
* [lld][ELF] Mark empty NOLOAD output sections SHT_NOBITS instead of SHT_PROGBITSMatt Schulte2020-06-161-3/+5
| | | | | | | | | | | This fixes PR# 45336. Output sections described in a linker script as NOLOAD with no input sections would be marked as SHT_PROGBITS. Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D76981 (cherry picked from commit fdc41aa22c60958e6b6df461174b814a4aae3384)
* [ELF][test] Make tests less address sensitive and delete redundant testsFangrui Song2020-06-167-164/+22
| | | | (cherry picked from commit 09ac859c136b406231ef7547f3800111dd00bc7e)
* [CodeView] Align type records on 4-bytes when emitting PDBsAlexandre Ganea2020-04-161-0/+46
| | | | | | | | | | | | | | | When emitting PDBs, the TypeStreamMerger class is used to merge .debug$T records from the input .OBJ files into the output .PDB stream. Records in .OBJs are not required to be aligned on 4-bytes, and "The Netwide Assembler 2.14" generates non-aligned records. When compiling with -DLLVM_ENABLE_ASSERTIONS=ON, an assert was triggered in MergingTypeTableBuilder when non-ghash merging was used. With ghash merging there was no assert. As a result, LLD could potentially generate a non-aligned TPI stream. We now align records on 4-bytes when record indices are remapped, in TypeStreamMerger::remapIndices(). Differential Revision: https://reviews.llvm.org/D75081 (cherry picked from commit a7325298e1f311b383b8ce5ba8e2d3698fef472a)
* [ELF] Allow SHF_LINK_ORDER and non-SHF_LINK_ORDER to be mixedFangrui Song2020-04-142-20/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, `error: incompatible section flags for .rodata` is reported when we mix SHF_LINK_ORDER and non-SHF_LINK_ORDER sections in an output section. This is overconstrained. This patch allows mixed flags with the requirement that SHF_LINK_ORDER sections must be contiguous. Mixing flags is used by Linux aarch64 (https://github.com/ClangBuiltLinux/linux/issues/953) .init.data : { ... KEEP(*(__patchable_function_entries)) ... } When the integrated assembler is enabled, clang's -fpatchable-function-entry=N[,M] implementation sets the SHF_LINK_ORDER flag (D72215) to fix a number of garbage collection issues. Strictly speaking, the ELF specification does not require contiguous SHF_LINK_ORDER sections but for many current uses of SHF_LINK_ORDER like .ARM.exidx/__patchable_function_entries there has been a requirement for the sections to be contiguous on top of the requirements of the ELF specification. This patch also imposes one restriction: SHF_LINK_ORDER sections cannot be separated by a symbol assignment or a BYTE command. Not allowing BYTE is a natural extension that a non-SHF_LINK_ORDER cannot be a separator. Symbol assignments can delimiter the contents of SHF_LINK_ORDER sections. Allowing SHF_LINK_ORDER sections across symbol assignments (especially __start_/__stop_) can make things hard to explain. The restriction should not be a problem for practical use cases. Reviewed By: psmith Differential Revision: https://reviews.llvm.org/D77007 (cherry picked from commit 673e81eee4fa3ffa38736f1063e6c4fa2d9278b0)
* [ELF][test] Improve linkerscript/linkorder.sFangrui Song2020-04-141-18/+48
| | | | (cherry picked from commit 2d19270efcf01672c8eaab1ccb0e5b89ea953cc9)
* [ELF][test] Rename SHF_LINK_ORDER related "metadata" to "linkorder"Fangrui Song2020-04-1411-62/+49
| | | | | | Test cleanups. (cherry picked from commit b305b8a256eade076bb13f52668a6015631ac0e5)
* [COFF] Don't treat DWARF sections as GC rootsReid Kleckner2020-04-131-0/+60
| | | | | | | | | | | | | | DWARF sections are typically live and not COMDAT, so they would be treated as GC roots. Enabling DWARF would essentially keep all code with debug info alive, preventing any section GC. Fixes PR45273 Reviewed By: mstorsjo, MaskRay Differential Revision: https://reviews.llvm.org/D76935 (cherry picked from commit c579a5b1d92a9bc2046d00ee2d427832e0f5ddec)
* [ELF] Fix a null pointer dereference when --emit-relocs and --strip-debug ↵Fangrui Song2020-04-101-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | are used together Fixes https://bugs.llvm.org//show_bug.cgi?id=44878 When --strip-debug is specified, .debug* are removed from inputSections while .rel[a].debug* (incorrectly) remain. LinkerScript::addOrphanSections() requires the output section of a relocated InputSectionBase to be created first. .debug* are not in inputSections -> output sections .debug* are not created -> getOutputSectionName(.rel[a].debug*) dereferences a null pointer. Fix the null pointer dereference by deleting .rel[a].debug* from inputSections as well. Reviewed By: grimar, nickdesaulniers Differential Revision: https://reviews.llvm.org/D74510 (cherry picked from commit 6c73246179376442705b3a545f4e1f1478777a04)
* Revert abb00753 "build: reduce CMake handling for zlib" (PR44780)Hans Wennborg2020-03-032-2/+11
| | | | | | | | | | | | | and follow-ups: a2ca1c2d "build: disable zlib by default on Windows" 2181bf40 "[CMake] Link against ZLIB::ZLIB" 1079c68a "Attempt to fix ZLIB CMake logic on Windows" This changed the output of llvm-config --system-libs, and more importantly it broke stand-alone builds. Instead of piling on more fix attempts, let's revert this to reduce the risk of more breakages. (cherry picked from commit 916be8fd6a0a0feea4cefcbeb0c22c65848d7a2e)
* [LLD][ELF][ARM][AArch64] Only round up ThunkSection Size when large OS.Peter Smith2020-02-044-17/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In D71281 a fix was put in to round up the size of a ThunkSection to the nearest 4KiB when performing errata patching. This fixed a problem with a very large instrumented program that had thunks and patches mutually trigger each other. Unfortunately it triggers an assertion failure in an AArch64 allyesconfig build of the kernel. There is a specific assertion preventing an InputSectionDescription being larger than 4KiB. This will always trigger if there is at least one Thunk needed in that InputSectionDescription, which is possible for an allyesconfig build. Abstractly the problem case is: .text : { *(.text) ; ... . = ALIGN(SZ_4K); __idmap_text_start = .; *(.idmap.text) __idmap_text_end = .; ... } The assertion checks that __idmap_text_end - __idmap_start is < 4 KiB. Note that there is more than one InputSectionDescription in the OutputSection so we can't just restrict the fix to OutputSections smaller than 4 KiB. The fix presented here limits the D71281 to InputSectionDescriptions that meet the following conditions: 1.) The OutputSection is bigger than the thunkSectionSpacing so adding thunks will affect the addresses of following code. 2.) The InputSectionDescription is larger than 4 KiB. This will prevent any assertion failures that an InputSectionDescription is < 4 KiB in size. We do this at ThunkSection creation time as at this point we know that the addresses are stable and up to date prior to adding the thunks as assignAddresses() will have been called immediately prior to thunk generation. The fix reverts the two tests affected by D71281 to their original state as they no longer need the 4KiB size roundup. I've added simpler tests to check for D71281 when the OutputSection size is larger than the ThunkSection spacing. Fixes https://github.com/ClangBuiltLinux/linux/issues/812 Differential Revision: https://reviews.llvm.org/D72344 (cherry picked from commit 01ad4c838466bd5db180608050ed8ccb3b62d136)
* [ELF] Decrease alignment of ThunkSection on 64-bit targets from 8 to 4Fangrui Song2020-02-0410-56/+56
| | | | | | | | | | | | | ThunkSection contains 4-byte instructions on all targets that use thunks. Thunks should not be used in any performance sensitive places, and locality/cache line/instruction fetching arguments should not apply. We use 16 bytes as preferred function alignments for modern PowerPC cores. In any case, 8 is not optimal. Differential Revision: https://reviews.llvm.org/D72819 (cherry picked from commit 870094decfc9fe80c8e0a6405421b7d09b97b02b)
* [LLD][ELF][ARM] Do not insert interworking thunks for non STT_FUNC symbolsPeter Smith2020-01-293-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ELF for the ARM architecture requires linkers to provide interworking for symbols that are of type STT_FUNC. Interworking for other symbols must be encoded directly in the object file. LLD was always providing interworking, regardless of the symbol type, this breaks some programs that have branches from Thumb state targeting STT_NOTYPE symbols that have bit 0 clear, but they are in fact internal labels in a Thumb function. LLD treats these symbols as ARM and inserts a transition to Arm. This fixes the problem for in range branches, R_ARM_JUMP24, R_ARM_THM_JUMP24 and R_ARM_THM_JUMP19. This is expected to be the vast majority of problem cases as branching to an internal label close to the function. There is at least one follow up patch required. - R_ARM_CALL and R_ARM_THM_CALL may do interworking via BL/BLX substitution. In theory range-extension thunks can be altered to not change state when the symbol type is not STT_FUNC. I will need to check with ld.bfd to see if this is the case in practice. Fixes (part of) https://github.com/ClangBuiltLinux/linux/issues/773 Differential Revision: https://reviews.llvm.org/D73474 (cherry picked from commit 4f38ab250ff4680375c4c01db0a88c157093c665)
* [ELF][PPC32] Support --emit-relocs link of R_PPC_PLTREL24Fangrui Song2020-01-281-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to R_MIPS_GPREL16 and R_MIPS_GPREL32 (D45972). If the addend of an R_PPC_PLTREL24 is >= 0x8000, it indicates that r30 is relative to the input section .got2. ``` addis 30, 30, .got2+0x8000-.L1$pb@ha addi 30, 30, .got2+0x8000-.L1$pb@l ... bl foo+0x8000@PLT ``` After linking, the relocation will be relative to the output section .got2. To compensate for the shift `address(input section .got2) - address(output section .got2) = ppc32Got2OutSecOff`, adjust by `ppc32Got2OutSecOff`: ``` addis 30, 30, .got2+0x8000-.L1+ppc32Got2OutSecOff$pb@ha addi 30, 30, .got2+0x8000-.L1+ppc32Got2OutSecOff$pb@ha$pb@l ... bl foo+0x8000+ppc32Got2OutSecOff@PLT ``` This rule applys to a relocatable link or a non-relocatable link with --emit-relocs. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73532 (cherry picked from commit e11b709b1922ca46b443fcfa5d76b87edca48721)
* [ELF][PPC32] Support range extension thunks with addendsFangrui Song2020-01-251-0/+87
| | | | | | | | | | | * Generalize the code added in D70637 and D70937. We should eventually remove the EM_MIPS special case. * Handle R_PPC_LOCAL24PC the same way as R_PPC_REL24. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73424 (cherry picked from commit 70389be7a029bec3c45991a60b627445ef996120)
* [ELF][PPC32] Support canonical PLTFangrui Song2020-01-251-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -fno-pie produces a pair of non-GOT-non-PLT relocations R_PPC_ADDR16_{HA,LO} (R_ABS) referencing external functions. ``` lis 3, func@ha la 3, func@l(3) ``` In a -no-pie/-pie link, if func is not defined in the executable, a canonical PLT entry (st_value>0, st_shndx=0) will be needed. References to func in shared objects will be resolved to this address. -fno-pie -pie should fail with "can't create dynamic relocation ... against ...", so we just need to think about -no-pie. On x86, the PLT entry passes the JMP_SLOT offset to the rtld PLT resolver. On x86-64: the PLT entry passes the JUMP_SLOT index to the rtld PLT resolver. On ARM/AArch64: the PLT entry passes &.got.plt[n]. The PLT header passes &.got.plt[fixed-index]. The rtld PLT resolver can compute the JUMP_SLOT index from the two addresses. For these targets, the canonical PLT entry can just reuse the regular PLT entry (in PltSection). On PPC32: PltSection (.glink) consists of `b PLTresolve` instructions and `PLTresolve`. The rtld PLT resolver depends on r11 having been set up to the .plt (GotPltSection) entry. On PPC64 ELFv2: PltSection (.glink) consists of `__glink_PLTresolve` and `bl __glink_PLTresolve`. The rtld PLT resolver depends on r12 having been set up to the .plt (GotPltSection) entry. We cannot reuse a `b PLTresolve`/`bl __glink_PLTresolve` in PltSection as a canonical PLT entry. PPC64 ELFv2 avoids the problem by using TOC for any external reference, even in non-pic code, so the canonical PLT entry scenario should not happen in the first place. For PPC32, we have to create a PLT call stub as the canonical PLT entry. The code sequence sets up r11. Reviewed By: Bdragon28 Differential Revision: https://reviews.llvm.org/D73399 (cherry picked from commit 837e8a9c0cd097034e023dfba146d17ce132998c)
* [lld][RISCV] Print error when encountering R_RISCV_ALIGNJames Clarke2020-01-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Unlike R_RISCV_RELAX, which is a linker hint, R_RISCV_ALIGN requires the support of the linker even when ignoring all R_RISCV_RELAX relocations. This is because the compiler emits as many NOPs as may be required for the requested alignment, more than may be required pre-relaxation, to allow for the target becoming more unaligned after relaxing earlier sequences. This means that the target is often not initially aligned in the object files, and so the R_RISCV_ALIGN relocations cannot just be ignored. Since we do not support linker relaxation, we must turn these into errors. Reviewers: ruiu, MaskRay, espindola Reviewed By: MaskRay Subscribers: grimar, Jim, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71820 (cherry picked from commit d1da63664f4e42191daf2e6a9fa682ca9f75ef5e)
* [ELF][PowerPC] Support R_PPC_COPY and R_PPC64_COPYFangrui Song2020-01-241-0/+29
| | | | | | | | Reviewed By: Bdragon28, jhenderson, grimar, sfertile Differential Revision: https://reviews.llvm.org/D73255 (cherry picked from commit f1dab29908d25a4044abff6ffc120c48b20f034d)
* [ELF] --no-dynamic-linker: don't emit undefined weak symbols to .dynsymFangrui Song2020-01-231-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | I felt really sad to push this commit for my selfish purpose to make glibc -static-pie build with lld. Some code constructs in glibc require R_X86_64_GOTPCREL/R_X86_64_REX_GOTPCRELX referencing undefined weak to be resolved to a GOT entry not relocated by R_X86_64_GLOB_DAT (GNU ld behavior), e.g. csu/libc-start.c if (__pthread_initialize_minimal != NULL) __pthread_initialize_minimal (); elf/dl-object.c void _dl_add_to_namespace_list (struct link_map *new, Lmid_t nsid) { /* We modify the list of loaded objects. */ __rtld_lock_lock_recursive (GL(dl_load_write_lock)); Emitting a GLOB_DAT will make the address equal &__ehdr_start (true value) and cause elf/ldconfig to segfault. glibc really should move away from weak references, which do not have defined semantics. Temporarily special case --no-dynamic-linker. (cherry picked from commit 0fbf28f7aae0ceb70071cac56de345e3ff04439c)
* [test] Fix lld/test/ELF/riscv-pcrel-hilo-error.s after D73211James Clarke2020-01-231-0/+6
| | | | (cherry picked from commit ddfe8751b16a1d57b0586fb48d1109c98234bc3f)
* [LLD][COFF] Enable linking of __declspec(selectany) symbols from Clang and GCCMarkus Böck2020-01-231-0/+13
| | | | | | | | | | | | When annotating a symbol with __declspec(selectany), Clang assigns it comdat 2 while GCC assigns it comdat 3. This patch enables two object files that contain a __declspec(selectany) symbol, one created by gcc and the other by clang, to be linked together instead of issuing a duplicate symbol error. Differential Revision: https://reviews.llvm.org/D73139 (cherry picked from commit 9dbc1ab23268abce5db98ad9a1e3aef89c371524)
* [ELF] Allow R_PLT_PC (R_PC) to a hidden undefined weak symbolFangrui Song2020-01-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | This essentially reverts b841e119d77ed0502e3a2e710f26a899bef28b3c. Such code construct can be used in the following way: // glibc/stdlib/exit.c // clang -fuse-ld=lld => succeeded // clang -fuse-ld=lld -fpie -pie => relocation R_PLT_PC cannot refer to absolute symbol __attribute__((weak, visibility("hidden"))) extern void __call_tls_dtors(); void __run_exit_handlers() { if (__call_tls_dtors) __call_tls_dtors(); } Since we allow R_PLT_PC in -no-pie mode, it makes sense to allow it in -pie mode as well. Reviewed By: pcc Differential Revision: https://reviews.llvm.org/D72943 (cherry picked from commit 6ab89c3c5df8b679e6ee240a13356309c048fc71)
* [ELF] Avoid false-positive assert in getErrPlace()Alex Richardson2020-01-171-1/+6
| | | | | | | | | | | | | This assertion was added as part of D70659 but did not account for .bss input sections. I noticed that this assert was incorrectly triggering while building FreeBSD for MIPS64. Fixed by relaxing the assert to also account for SHT_NOBITS input sections and adjust the test mips-jalr-non-function.s to link a file with a .bss section first. Reviewed By: MaskRay, grimar Differential Revision: https://reviews.llvm.org/D72567 (cherry picked from commit 441410be471d5d0a5d1d47cf363de155e397a0c2)
* [ELF] -r: don't create .interpFangrui Song2020-01-161-2/+7
| | | | | | | | | | | | | `{clang,gcc} -nostdlib -r a.c` passes --dynamic-linker to the linker, and the expected behavior is to ignore it. If .interp is kept in the relocatable object file, a final link will get PT_INTERP even if --dynamic-linker is not specified. glibc ld.so expects to see PT_DYNAMIC and the executable will likely fail to run. Ignore --dynamic-linker in -r mode as well as -shared. (cherry picked from commit 2d7a8cf90478cd845ffb39763b0e95b7715322d2)
* [ELF] --exclude-libs: don't assign VER_NDX_LOCAL to undefined symbolsFangrui Song2020-01-141-0/+19
| | | | | | | | | | | | | | | Suggested by Peter Collingbourne. Non-VER_NDX_GLOBAL versions should not be assigned to defined symbols. --exclude-libs violates this and can cause a spurious error "cannot refer to absolute symbol" after D71795. excludeLibs incorrectly assigns VER_NDX_LOCAL to an undefined weak symbol => isPreemptible is false => R_PLT_PC is optimized to R_PC => in isStaticLinkTimeConstant, an error is emitted. Reviewed By: pcc, grimar Differential Revision: https://reviews.llvm.org/D72681
* [ELF] Add -z force-ibt and -z shstk for Intel Control-flow Enforcement ↵Fangrui Song2020-01-134-95/+185
| | | | | | | | | | | | | | | | | | | | | | | | | | | Technology This patch is a joint work by Rui Ueyama and me based on D58102 by Xiang Zhang. It adds Intel CET (Control-flow Enforcement Technology) support to lld. The implementation follows the draft version of psABI which you can download from https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI. CET introduces a new restriction on indirect jump instructions so that you can limit the places to which you can jump to using indirect jumps. In order to use the feature, you need to compile source files with -fcf-protection=full. * IBT is enabled if all input files are compiled with the flag. To force enabling ibt, pass -z force-ibt. * SHSTK is enabled if all input files are compiled with the flag, or if -z shstk is specified. IBT-enabled executables/shared objects have two PLT sections, ".plt" and ".plt.sec". For the details as to why we have two sections, please read the comments. Reviewed By: xiangzhangllvm Differential Revision: https://reviews.llvm.org/D59780
* [MIPS][ELF] Use PC-relative relocations in .eh_frame when possibleAlex Richardson2020-01-131-0/+58
| | | | | | | | | | | | | | | | | | | | 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
* [MC][ELF] Emit a relocation if target is defined in the same section and is ↵Fangrui Song2020-01-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-local For a target symbol defined in the same section, currently we don't emit a relocation if VariantKind is VK_None (with few exceptions like RISC-V relaxation), while GNU as emits one. This causes program behavior differences with and without -ffunction-sections, and can break intended symbol interposition in a -shared link. ``` .globl foo foo: call foo # no relocation. On other targets, may be written as b foo, etc call bar # a relocation if bar is in another section (e.g. -ffunction-sections) call foo@plt # a relocation ``` Unify these cases by always emitting a relocation. If we ever want to optimize `call foo` in -shared links, we should emit a STB_LOCAL alias and call via the alias. ARM/thumb2-beq-fixup.s: we now emit a relocation to global_thumb_fn as GNU as does. X86/Inputs/align-branch-64-2.s: we now emit R_X86_64_PLT32 to foo as GNU does. ELF/relax.s: rewrite the test as target-in-same-section.s . We omitted relocations to `global` and now emit R_X86_64_PLT32. Note, GNU as does not emit a relocation for `jmp global` (maybe its own bug). Our new behavior is compatible except `jmp global`. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D72197
* [COFF] Align ARM64 range extension thunks at instruction boundaryTom Tan2020-01-101-2/+18
| | | | | | | | | | | | | | | RangeExtensionThunkARM64 is created for out-of-range branches on Windows ARM64 because branch instructions has limited bits to encode target address. Currently, RangeExtensionThunkARM64 is appended to its referencing COFF section from object file at link time without any alignment requirement, so if size of the preceding COFF section is not aligned to instruction boundary (4 bytes), RangeExtensionThunkARM64 will emit thunk instructions at unaligned address which is never a valid branch target on ARM64, and usually triggers invalid instruction exception when branching to it. This PR fixes it by requiring such thunks to align at 4 bytes. Differential revision: https://reviews.llvm.org/D72473
* [lld][WebAssembly] Add libcall symbols to the link when LTO is being used.Sam Clegg2020-01-102-0/+31
| | | | | | | | | | | | | | | This code is copied almost verbatim from the equivalent change to the ELF linker: - https://reviews.llvm.org/D50017 - https://reviews.llvm.org/D50475 The upshot is that libraries containing libcall (such as compiler-rt and libc) can be compiled with LTO. Fixes PR41384 Differential Revision: https://reviews.llvm.org/D71738
* [ELF] Make TargetInfo::writeIgotPlt a no-opFangrui Song2020-01-102-4/+4
| | | | | | | | | | | | | | RELA targets don't read initial .got.plt entries. REL targets (ARM, x86-32) write the address of the IFUNC resolver to the entry (`write32le(buf, s.getVA())`). The default writeIgotPlt() is not meaningful. Make it a no-op. AArch64 and x86-64 will have 0 as initial .got.plt entries associated with IFUNC. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D72474
* [DebugInfo] Improve error message textJames Henderson2020-01-101-1/+1
| | | | | | | | | | Unlike most of our errors in the debug line parser, the "no end of sequence" message was missing any reference to which line table it refererred to. This change adds the offset to this message. Reviewed by: dblaikie Differential Revision: https://reviews.llvm.org/D72443
* [ThinLTO] Pass CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLPWei Mi2020-01-091-0/+48
| | | | | | | | | | | | | down to pass builder in ltobackend. Currently CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLP in clang are not passed down to pass builder in ltobackend when new pass manager is used. This is inconsistent with the behavior when new pass manager is used and thinlto is not used. Such inconsistency causes slp vectorization pass not being enabled in ltobackend for O3 + thinlto right now. This patch fixes that. Differential Revision: https://reviews.llvm.org/D72386
* [ELF] Fix includeInDynsym() when an undefined weak is merged with a lazy ↵Fangrui Song2020-01-091-0/+5
| | | | | | | | | | | | definition An undefined weak does not fetch the lazy definition. A lazy weak symbol should be considered undefined, and thus preemptible if .dynsym exists. D71795 is not quite an NFC. It errors on an R_X86_64_PLT32 referencing an undefined weak symbol. isPreemptible is false (incorrect) => R_PLT_PC is optimized to R_PC => in isStaticLinkTimeConstant, an error is emitted when an R_PC is applied on an undefined weak (considered absolute).
* Re-apply "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"Alex Richardson2020-01-091-2/+2
| | | | | | This time with a fix for the UBSAN failure. Differential Revision: https://reviews.llvm.org/D70659
* [ELF][Hexagon] Add support for IE relocationsSid Manning2020-01-091-0/+78
| | | | Differential Revision: https://reviews.llvm.org/D71143
* [LLD] [COFF] Fix post-commit suggestions for absolute symbol equalityMartin Storsjö2020-01-081-2/+2
| | | | Differential Revision: https://reviews.llvm.org/D72252
* [ELF] Don't special case weak symbols for pie with no shared objectsFangrui Song2020-01-082-35/+7
| | | | | | | | | | | | | | | | | | | | | | D59275 added the following clause to Symbol::includeInDynsym() if (isUndefWeak() && Config->Pie && SharedFiles.empty()) return false; D59549 explored the possibility to generalize it for -no-pie. GNU ld's rules are architecture dependent and partly controlled by -z {,no-}dynamic-undefined-weak. Our attempts to mimic its rules are actually half-baked and don't provide perceivable benefits (it can save a few more weak undefined symbols in .dynsym in a -static-pie executable). Let's just delete the rule for simplicity. We will expect cosmetic inconsistencies with ld.bfd in certain -static-pie scenarios. This permits a simplification in D71795. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D71794
* [LLD][ELF][AArch64] Do not use thunk for undefined weak symbol.Peter Smith2020-01-072-28/+29
| | | | | | | | | | | | | | | In AArch64 a branch to an undefined weak symbol that does not have a PLT entry should resolve to the next instruction. The thunk generation code can prevent this from happening as a range extension thunk can be generated if the branch is sufficiently far away from 0, the value of an undefined weak symbol. The fix is taken from the Arm implementation of needsThunk(), we prevent a thunk from being generated to an undefined weak symbol. fixes pr44451 Differential Revision: https://reviews.llvm.org/D72267
* [lld] Fix trivial typos in commentsKazuaki Ishizaki2020-01-065-5/+5
| | | | | | Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D72196
* [llvm-readelf] Print EI_ABIVERSION as decimal instead of hexadecimalFangrui Song2020-01-061-1/+1
| | | | | | | | This matches GNU readelf and llvm-readobj. Reviewed By: jhenderson Differential Revision: https://reviews.llvm.org/D72234
* [LLD] [COFF] Don't error out on duplicate absolute symbols with the same valueMartin Storsjö2020-01-042-1/+15
| | | | | | | | | Both MS link.exe and GNU ld.bfd handle it this way; one can have multiple object files defining the same absolute symbols, as long as it defines it to the same value. But if there are multiple absolute symbols with differing values, it is treated as an error. Differential Revision: https://reviews.llvm.org/D71981
* [test][ELF] Use CHECK-NEXT to properly verify error messagesJames Henderson2020-01-031-34/+36
| | | | | | Reviewed By: MaskRay Differential Revision: https://reviews.llvm.org/D72092
* [PDB] Print the most redundant type record indices with /summaryReid Kleckner2020-01-021-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: I used this information to motivate splitting up the Intrinsic::ID enum (5d986953c8b917bacfaa1f800fc1e242559f76be) and adding a key method to clang::Sema (586f65d31f32ca6bc8cfdb8a4f61bee5057bf6c8) which saved a fair amount of object file size. Example output for clang.pdb: Top 10 types responsible for the most TPI input bytes: index total bytes count size 0x3890: 8,671,220 = 1,805 * 4,804 0xE13BE: 5,634,720 = 252 * 22,360 0x6874C: 5,181,600 = 408 * 12,700 0x2A1F: 4,520,528 = 1,574 * 2,872 0x64BFF: 4,024,020 = 469 * 8,580 0x1123: 4,012,020 = 2,157 * 1,860 0x6952: 3,753,792 = 912 * 4,116 0xC16F: 3,630,888 = 633 * 5,736 0x69DD: 3,601,160 = 985 * 3,656 0x678D: 3,577,904 = 319 * 11,216 In this case, we can see that record 0x3890 is responsible for ~8MB of total object file size for objects in clang. The user can then use llvm-pdbutil to find out what the record is: $ llvm-pdbutil dump -types -type-index 0x3890 Types (TPI Stream) ============================================================ Showing 1 records. 0x3890 | LF_FIELDLIST [size = 4804] - LF_STMEMBER [name = `WORDTYPE_MAX`, type = 0x1001, attrs = public] - LF_MEMBER [name = `U`, Type = 0x37F0, offset = 0, attrs = private] - LF_MEMBER [name = `BitWidth`, Type = 0x0075 (unsigned), offset = 8, attrs = private] - LF_METHOD [name = `APInt`, # overloads = 8, overload list = 0x3805] ... In this case, we can see that these are members of the APInt class, which is emitted in 1805 object files. The next largest type is ASTContext: $ llvm-pdbutil dump -types -type-index 0xE13BE bin/clang.pdb 0xE13BE | LF_FIELDLIST [size = 22360] - LF_BCLASS type = 0x653EA, offset = 0, attrs = public - LF_MEMBER [name = `Types`, Type = 0x653EB, offset = 8, attrs = private] - LF_MEMBER [name = `ExtQualNodes`, Type = 0x653EC, offset = 24, attrs = private] - LF_MEMBER [name = `ComplexTypes`, Type = 0x653ED, offset = 48, attrs = private] - LF_MEMBER [name = `PointerTypes`, Type = 0x653EE, offset = 72, attrs = private] ... ASTContext only appears 252 times, but the list of members is long, and must be repeated everywhere it is used. This was the output before I split Intrinsic::ID: Top 10 types responsible for the most TPI input: 0x686C: 69,823,920 = 1,070 * 65,256 0x686D: 69,819,640 = 1,070 * 65,252 0x686E: 69,819,640 = 1,070 * 65,252 0x686B: 16,371,000 = 1,070 * 15,300 ... These records were all lists of intrinsic enums. Reviewers: MaskRay, ruiu Subscribers: mgrang, zturner, thakis, hans, akhuang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71437
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-022-11/+2
| | | | | | | | | | | | | Rather than handling zlib handling manually, use `find_package` from CMake to find zlib properly. Use this to normalize the `LLVM_ENABLE_ZLIB`, `HAVE_ZLIB`, `HAVE_ZLIB_H`. Furthermore, require zlib if `LLVM_ENABLE_ZLIB` is set to `YES`, which requires the distributor to explicitly select whether zlib is enabled or not. This simplifies the CMake handling and usage in the rest of the tooling. This restores 68a235d07f9e7049c7eb0c8091f37e385327ac28, e6c7ed6d2164a0659fd9f6ee44f1375d301e3cad. The problem with the windows bot is a need for clearing the cache.
* [ELF][Hexagon][test] Use llvm-readobj to check relocations. NFCFangrui Song2020-01-021-3/+8
| | | | | | Reviewed By: sidneym Differential Revision: https://reviews.llvm.org/D72093
* Add TPREL relocation support to HexagonSid Manning2020-01-021-0/+56
| | | | Differential Revision: https://reviews.llvm.org/D71069
* [test][ELF] Verify debug line corruption messages are printed onceJames Henderson2020-01-022-9/+30
| | | | | | | | | | | | | LLD warns if it encounters malformed debug data when parsing line information for an undefined reference. We only want to warn once. This patch adds additional checking to make sure the warnings are printed only once, both for variables within the same program and variables in later line programs. Reviewed by: grimar, MaskRay Differential Revision: https://reviews.llvm.org/D71759
* Revert "build: reduce CMake handling for zlib"James Henderson2020-01-022-2/+11
| | | | | | | This reverts commit 68a235d07f9e7049c7eb0c8091f37e385327ac28. This commit broke the clang-x64-windows-msvc build bot and a follow-up commit did not fix it. Reverting to fix the bot.
OpenPOWER on IntegriCloud