summaryrefslogtreecommitdiffstats
path: root/lld/test
Commit message (Collapse)AuthorAgeFilesLines
...
* build: reduce CMake handling for zlibSaleem Abdulrasool2020-01-012-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.
* [ELF][RISCV][test] Test absolute/PC-relative/branch relocations to undefined ↵Fangrui Song2019-12-311-0/+79
| | | | weak symbols
* [ELF][PPC64] Improve "call lacks nop" diagnostic and make it compatible with ↵Fangrui Song2019-12-293-3/+9
| | | | | | | | | | | | | | | | GCC<5.5 and GCC<6.4 GCC before r245813 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439) did not emit nop after b/bl. This can happen with recursive calls. r245813 was back ported to GCC 5.5 and GCC 6.4. This is common, for example, libstdc++.a(locale.o) shipped with GCC 4.9 and many objects in netlib lapack can cause lld to error. gold allows such calls to the same section. Our __plt_foo symbol's `section` field is used for ThunkSection, so we can't implement a similar loosen rule easily. But we can make use of its `file` field which is currently NULL. Differential Revision: https://reviews.llvm.org/D71639
* [ELF][PPC32] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-292-14/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similar to D71509 (EM_PPC64), on EM_PPC, the IPLT code sequence should be similar to a PLT call stub. Unlike EM_PPC64, EM_PPC -msecure-plt has small/large PIC model differences. * -fpic/-fpie: R_PPC_PLTREL24 r_addend=0. The call stub loads an address relative to `_GLOBAL_OFFSET_TABLE_`. * -fPIC/-fPIE: R_PPC_PLTREL24 r_addend=0x8000. (A partial linked object file may have an addend larger than 0x8000.) The call stub loads an address relative to .got2+0x8000. Just assume large PIC model for now. This patch makes: // clang -fuse-ld=lld -msecure-plt -fno-pie -no-pie a.c // clang -fuse-ld=lld -msecure-plt -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc. -fpie will crash because the compiler and the linker do not agree on the value which r30 stores (_GLOBAL_OFFSET_TABLE_ vs .got2+0x8000). Differential Revision: https://reviews.llvm.org/D71621
* [ELF][PPC64] Implement IPLT code sequence for non-preemptible IFUNCFangrui Song2019-12-292-29/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Non-preemptible IFUNC are placed in in.iplt (.glink on EM_PPC64). If there is a non-GOT non-PLT relocation, for pointer equality, we change the type of the symbol from STT_IFUNC and STT_FUNC and bind it to the .glink entry. On EM_386, EM_X86_64, EM_ARM, and EM_AARCH64, the PLT code sequence loads the address from its associated .got.plt slot. An IPLT also has an associated .got.plt slot and can use the same code sequence. On EM_PPC64, the PLT code sequence is actually a bl instruction in .glink . It jumps to `__glink_PLTresolve` (the PLT header). and `__glink_PLTresolve` computes the .plt slot (relocated by R_PPC64_JUMP_SLOT). An IPLT does not have an associated R_PPC64_JUMP_SLOT, so we cannot use `bl` in .iplt . Instead, create a call stub which has a similar code sequence as PPC64PltCallStub. We don't save the TOC pointer, so such scenarios will not work: a function pointer to a non-preemptible ifunc, which resolves to a function defined in another DSO. This is the restriction described by https://sourceware.org/glibc/wiki/GNU_IFUNC (though on many architectures it works in practice): Requirement (a): Resolver must be defined in the same translation unit as the implementations. If an ifunc is taken address but not called, technically we don't need an entry for it, but we currently do that. This patch makes // clang -fuse-ld=lld -fno-pie -no-pie a.c // clang -fuse-ld=lld -fPIE -pie a.c #include <stdio.h> static void impl(void) { puts("meow"); } void thefunc(void) __attribute__((ifunc("resolver"))); void *resolver(void) { return &impl; } int main(void) { thefunc(); void (*theptr)(void) = &thefunc; theptr(); } work on Linux glibc and FreeBSD. Calling a function pointer pointing to a Non-preemptible IFUNC never worked before. Differential Revision: https://reviews.llvm.org/D71509
* [ELF] Improve the condition to create .interpFangrui Song2019-12-272-9/+7
| | | | | | | | | | | | | | | This restores commit 1417558e4a61794347c6bfbafaff7cd96985b2c3 and its follow-up, reverted by commit c3dbd782f1e0578c7ebc342f2e92f54d9644cff7. After this commit: clang -fuse-ld=bfd -no-pie -nostdlib a.c => .interp not created clang -fuse-ld=bfd -pie -fPIE -nostdlib a.c => .interp created clang -fuse-ld=gold -no-pie -nostdlib a.c => .interp not created clang -fuse-ld=gold -pie -fPIE -nostdlib a.c => .interp created clang -fuse-ld=lld -no-pie -nostdlib a.c => .interp created clang -fuse-ld=lld -pie -fPIE -nostdlib a.c => .interp created
* Revert "[ELF] Improve the condition to create .interp"Reid Kleckner2019-12-272-7/+9
| | | | | | | | This reverts commit 1417558e4a61794347c6bfbafaff7cd96985b2c3. Also reverts commit 019a92bb2832447092bb5c1faf9d03bb03b8c9c8. This causes check-sanitizer to fail. The "-Nolib" variant of the test crashes on startup in the loader.
* [ELF][test] Fix dynamic-linker.sFangrui Song2019-12-261-2/+2
|
* [ELF] Improve the condition to create .interpFangrui Song2019-12-262-7/+5
| | | | | | | | | | | | | | | | | Similar to rL362355, but with the `!config->shared` guard. (1) {gcc,clang} -fuse-ld=bfd -pie -fPIE -nostdlib a.c => .interp created (2) {gcc,clang} -fuse-ld=lld -pie -fPIE -nostdlib a.c => .interp not created (3) {gcc,clang} -fuse-ld=lld -pie -fPIE -nostdlib a.c a.so => .interp created The inconsistency of (2) is due to the condition `!Config->SharedFiles.empty()`. To make lld behave more like ld.bfd, we could change the condition to: config->hasDynSymTab && !config->dynamicLinker.empty() && script->needsInterpSection(); However, that would bring another inconsistency as can be observed with: (4) {gcc,clang} -fuse-ld=bfd -no-pie -nostdlib a.c => .interp not created
* [ELF] Support input section description .gnu.version* in /DISCARD/Fangrui Song2019-12-261-0/+47
| | | | | | | | | | | | | | Linux powerpc discards `*(.gnu.version*)` (arch/powerpc/kernel/vmlinux.lds.S) to suppress --orphan-handling=warn warnings in the -pie output `.tmp_vmlinux1` The support is simple. Just add isLive() to: 1) Fix an assertion in SectionBase::getPartition() called by VersionTableSection::isNeeded(). 2) Suppress DT_VERSYM, DT_VERDEF, DT_VERNEED and DT_VERNEEDNUM, if the relevant section is discarded. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D71819
* [llvm-nm] Display STT_GNU_IFUNC as 'i'Fangrui Song2019-12-251-2/+2
| | | | | | Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D71803
* Migrate function attribute "no-frame-pointer-elim"="false" to ↵Fangrui Song2019-12-245-8/+8
| | | | "frame-pointer"="none" as cleanups after D56351
* Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" ↵Fangrui Song2019-12-242-2/+2
| | | | as cleanups after D56351
* [ELF] Don't suggest an alternative spelling for a symbol in a discarded sectionFangrui Song2019-12-231-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | For undef-not-suggest.test, we currently make redundant alternative spelling suggestions: ``` ld.lld: error: relocation refers to a discarded section: .text.foo >>> defined in a.o >>> section group signature: foo >>> prevailing definition is in a.o >>> referenced by a.o:(.rodata+0x0) >>> did you mean: >>> defined in: a.o ld.lld: error: relocation refers to a symbol in a discarded section: foo >>> defined in a.o >>> section group signature: foo >>> prevailing definition is in a.o >>> referenced by a.o:(.rodata+0x8) >>> did you mean: for >>> defined in: a.o ``` Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71735
* [lld][RISCV] Use an e_flags of 0 if there are only binary input files.John Baldwin2019-12-211-0/+8
| | | | | | | | | | | | | | | | | | Summary: If none of the input files are ELF object files (for example, when generating an object file from a single binary input file via "-b binary"), use a fallback value for the ELF header flags instead of crashing with an assertion failure. Reviewers: MaskRay, ruiu, espindola Reviewed By: MaskRay, ruiu Subscribers: kevans, grimar, emaste, arichardson, asb, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, sameer.abuasal, apazos, luismarques, llvm-commits, jrtc27 Tags: #llvm Differential Revision: https://reviews.llvm.org/D71101
* [LLD] [COFF] Fix reporting duplicate errors for absolute symbolsMartin Storsjö2019-12-191-0/+14
| | | | | | | | | | | | | | Previously this caused crashes in the reportDuplicate method. A DefinedAbsolute doesn't have any InputFile attached to it, so we can't report the file for the original symbol. We could add an InputFile argument to SymbolTable::addAbsolute only for the sake of error reporting, but even then it'd be assymetrical, only pointing out the file containing the new conflicting definition, not the original one. Differential Revision: https://reviews.llvm.org/D71679
* [ELF] Rename .plt to .iplt and decrease EM_PPC{,64} alignment of .glink to 4Fangrui Song2019-12-1720-51/+70
| | | | | | | | | | | | | | | | | | | | | | GNU ld creates the synthetic section .iplt, and has a built-in linker script that assigns .iplt to the output section .plt . There is no output section named .iplt . Making .iplt an output section actually has a benefit that makes the tricky toolchain feature stand out. Symbolizers don't have to deal with mixed PLT entries (e.g. llvm-objdump -d incorrectly annotates such jump targets). On EM_PPC{,64}, .glink contains a PLT resolver and a series of jump instructions. The 4-byte entry size makes it unnecessary to have an alignment of 16. Mark ppc32-gnu-ifunc.s and ppc32-gnu-ifunc-nonpreemptable.s as `XFAIL: *`. They test IPLT on EM_PPC, which never works. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D71520
* [ELF] Add IpltSectionFangrui Song2019-12-175-9/+9
| | | | | | | | | | | | | | | | | | | PltSection is used by both PLT and IPLT. The PLT section may have a header while the IPLT section does not. Split off IpltSection from PltSection to be clearer. Unlike other targets, PPC64 cannot use the same code sequence for PLT and IPLT. This helps make a future PPC64 patch (D71509) more isolated. On EM_386 and EM_X86_64, when PLT is empty while IPLT is not, currently we are inconsistent whether the PLT header is conceptually attached to in.plt or in.iplt . Consistently attach the header to in.plt can make the -z retpolineplt logic simpler. It also makes `jmp` point to an aesthetically better place for non-retpolineplt cases. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71519
* [ELF] Delete relOff from TargetInfo::writePLTFangrui Song2019-12-162-4/+4
| | | | | | | | | | | | | | This change only affects EM_386. relOff can be computed from `index` easily, so it is unnecessarily passed as a parameter. Both in.plt and in.iplt entries are written by writePLT. For in.iplt, the instruction `push reloc_offset` will change because `index` is now different. Fortunately, this does not matter because `push; jmp` is only used by PLT. IPLT does not need the code sequence. Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71518
* Revert "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"Vlad Tsyrklevich2019-12-131-2/+2
| | | | | | This reverts commit 2bbd32f5e8f0f62d895966e2623d9bdb9778b50b, it was causing UBSan failures like the following: lld/ELF/Target.cpp:103:41: runtime error: applying non-zero offset 24 to null pointer
* [ELF] Update st_size when merging a common symbol with a shared symbolFangrui Song2019-12-131-0/+16
| | | | | | | | | | | | | | | | | | When a common symbol is merged with a shared symbol, increase st_size if the shared symbol has a larger st_size. At runtime, the executable's symbol overrides the shared symbol. The shared symbol may be created from common symbols in a previous link. This rule makes sure we pick the largest size among all common symbols. This behavior matches GNU ld. See https://sourceware.org/bugzilla/show_bug.cgi?id=25236 for discussions. A shared symbol does not hold alignment constraints. Ignore the alignment update. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D71161
* [ELF] Allow getErrPlace() to work before Out::bufferStart is setAlex Richardson2019-12-131-2/+2
| | | | | | | | | | | | | | | | | | Summary: So far it seems like the only test affected by this change is the one I recently added for R_MIPS_JALR relocations since the other test cases that use this function early (unknown-relocation-*) do not have a valid input section for the relocation offset. Reviewers: ruiu, grimar, MaskRay, espindola Reviewed By: ruiu, MaskRay Subscribers: emaste, sdardis, jrtc27, atanasyan, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70659
* Revert an accidental commit af5ca40b47b3e85c3add81ccdc0b787c4bc355aeRui Ueyama2019-12-132-82/+0
|
* temporaryRui Ueyama2019-12-132-0/+82
|
* [WebAssembly] Add new `export_name` clang attribute for controlling wasm ↵Sam Clegg2019-12-111-0/+28
| | | | | | | | | | | | | | | | | | | | 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
* [ELF][AArch64] Rename --force-bti to -z force-bti and --pac-plt to -z pac-pltFangrui Song2019-12-114-13/+13
| | | | | | | | | | | | | | | | | | | Summary: The original design used --foo but the upstream complained that ELF only options should be -z foo. See https://sourceware.org/ml/binutils/2019-04/msg00151.html https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=8bf6d176b0a442a8091d338d4af971591d19922c made the rename. Our --force-bti and --pac-plt implement the same functionality, so it seems wise to be consistent with GNU ld. Reviewed By: peter.smith Subscribers: emaste, arichardson, kristof.beyls, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71327
* [LLD][ELF][AArch64][ARM] When errata patching, round thunk size to 4KiB.Peter Smith2019-12-112-43/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On some edge cases such as Chromium compiled with full instrumentation we have a .text section over twice the size of the maximum branch range and the instrumented code generation containing many examples of the erratum sequence. The combination of Thunks and many erratum sequences causes finalizeAddressDependentContent() to not converge. We end up with: start - Thunk Creation (disturbs addresses after thunks, creating more patches) - Patch Creation (disturbs addresses after patches, creating more thunks) - goto start In most images with few thunks and patches the mutual disturbance does not cause convergence problems. As the .text size and number of patches go up the risk increases. A way to prevent the thunk creation from interfering with patch creation is to round up the size of the thunks to a 4KiB boundary when the erratum patch is enabled. As the erratum sequence only triggers when an instruction sequence starts at 0xff8 or 0xffc modulo (4 KiB) by making the thunks not affect addresses modulo (4 KiB) we prevent thunks from interfering with the patch. The patches themselves could be aggregated in the same way that Thunks are within ThunkSections and we could round up the size in the same way. This would reduce the number of patches created in a .text section size > 128 MiB but would not likely help convergence problems. Differential Revision: https://reviews.llvm.org/D71281 fixes (remaining part of) pr44071, other part in D71242
* [LLD][ELF][AArch64][ARM] Add missing classof to patch sections.Peter Smith2019-12-111-0/+87
| | | | | | | | | | | | | The code to insert patch section merges them with a comparison function that uses logic of the form: return (isa<PatchSection>(a) && !isa<PatchSection>(b)); If the PatchSections don't implement classof this check fails if b is also a SyntheticSection. This can result in the patches being out of range if the SyntheticSection is big, for example a ThunkSection with lots of thunks. Differential Revision: https://reviews.llvm.org/D71242 fixes (part of) pr44071
* [ELF] --icf: do not fold preemptible symbolsFangrui Song2019-12-101-0/+49
| | | | | | | | | | | | | | | Fixes PR44124. A preemptible symbol may refer to a different definition at runtime. When comparing a pair of relocations, if they refer to different symbols, and either symbol is preemptible, the two containing sections should be considered different. gold has a similar rule https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ce97fa81e0c46d216b80b143ad8c02fff6906fef Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D71163
* [ELF] Refine section group --gc-sections rules to not discard .debug_typesFangrui Song2019-12-102-2/+14
| | | | | | | | | | | | | | | | | | | clang/gcc -fdebug-type-sections places .debug_types and .rela.debug_types in a section group, with a signature symbol which represents the type signature. The section group is for deduplication purposes. After D70146, we will discard such section groups. Refine the rule so that we will retain the group if no member has the SHF_ALLOC flag. GNU ld has a similar rule to retain the group if all members have the SEC_DEBUGGING flag. We try to be more general for future-proof purposes: if other non-SHF_ALLOC sections have deduplication needs, they may be placed in a section group. Don't discard them. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D71157
* [WebAssebmly][MC] Support .import_name/.import_field asm directivesSam Clegg2019-12-061-0/+0
| | | | | | | | Convert the MC test to use asm rather than bitcode. This is a precursor to https://reviews.llvm.org/D70520. Differential Revision: https://reviews.llvm.org/D70877
* [ELF][PPC64] Support long branch thunks with addendsFangrui Song2019-12-053-191/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PPC64 part of PR40438 // clang -target ppc64le -c a.cc // .text.unlikely may be placed in a separate output section (via -z keep-text-section-prefix) // The distance between bar in .text.unlikely and foo in .text may be larger than 32MiB. static void foo() {} __attribute__((section(".text.unlikely"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for PPC64. AArch64: .text -> `__AArch64ADRPThunk_ (adrp x16, ...; add x16, x16, ...; br x16)` -> target PPC64: .text -> `__long_branch_ (addis 12, 2, ...; ld 12, ...(12); mtctr 12; bctr)` -> target AArch64 can leverage ADRP to jump to the target directly, but PPC64 needs to load an address from .branch_lt . Before Power ISA v3.0, the PC-relative ADDPCIS was not available. .branch_lt was invented to work around the limitation. Symbol::ppc64BranchltIndex is replaced by PPC64LongBranchTargetSection::entry_index which take addends into consideration. The tests are rewritten: ppc64-long-branch.s tests -no-pie and ppc64-long-branch-pi.s tests -pie and -shared. Reviewed By: sfertile Differential Revision: https://reviews.llvm.org/D70937
* [LLD][ELF][AArch64] .note.gnu.property sections should have alignment 8Peter Smith2019-12-053-2/+84
| | | | | | | | | | | The .note.gnu.property SHT_NOTE sections on AArch64 (a 64-bit target) should have alignment 8 to more closely match the binutils implementation where alignment is 4-bytes on 32-bit machines and 8-bytes on 64-bit machines. Previously LLD was using 4 for both 32-bit and 64-bit machines. Differential Revision: https://reviews.llvm.org/D70962
* [LLD][ELF] Add support for PT_GNU_PROPERTYPeter Smith2019-12-055-222/+270
| | | | | | | | | | The PT_GNU_PROPERTY program header describes the location of the .note.gnu.property SHT_NOTES section. The linux kernel uses this program header to find the .note.gnu.property section rather than parsing. Executables that have properties that the kernel needs to act on that don't have the PT_GNU_PROPERTY program header will not boot. Differential Revision: https://reviews.llvm.org/D70961
* [ELF][AArch64] Support R_AARCH64_{CALL26,JUMP26} range extension thunks with ↵Fangrui Song2019-12-022-9/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | addends Fixes AArch64 part of PR40438 The current range extension thunk framework does not handle a relocation relative to a STT_SECTION symbol with a non-zero addend, which may be used by jumps/calls to local functions on some RELA targets (AArch64, powerpc ELFv1, powerpc64 ELFv2, etc). See PR40438 and the following code for examples: // clang -target $target a.cc // .text.cold may be placed in a separate output section. // The distance between bar in .text.cold and foo in .text may be larger than 128MiB. static void foo() {} __attribute__((section(".text.cold"))) static int bar() { foo(); return 0; } __attribute__((used)) static int dummy = bar(); This patch makes such thunks with addends work for AArch64. The target independent part can be reused by PPC in the future. On REL targets (ARM, MIPS), jumps/calls are not represented as STT_SECTION + non-zero addend (see MCELFObjectTargetWriter::needsRelocateWithSymbol), so they don't need this feature, but we need to make sure this patch does not affect them. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D70637
* [llvm-readobj] - Always print "Predecessors" for version definition sections.Georgii Rymar2019-11-273-0/+11
| | | | | | | | | | | | | This is a follow-up discussed in D70495 thread. The current logic is unusual for llvm-readobj. It doesn't print predecessors list when it is empty. This is not good for machine parsers. D70495 had to add this condition during refactoring to reduce amount of changes, in tests, because the original code also had a similar logic. Now seems it is time to get rid of it. This patch does it. Differential revision: https://reviews.llvm.org/D70717
* [ELF] Adjust test to work for zlib 1.2.8Shoaib Meenai2019-11-261-2/+2
| | | | | | The previous data had the same length with compression levels 1 and 6 for zlib 1.2.8. Adjust the test to work for this library version. I've also tested this with zlib 1.2.7 and zlib 1.2.11.
* [ELF] Add a corrector for case mismatch problemsFangrui Song2019-11-261-0/+10
| | | | | | Reviewed By: grimar, peter.smith Differential Revision: https://reviews.llvm.org/D70506
* [LLD][ELF] - Make compression level be dependent on -On.Georgii Rymar2019-11-261-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently LLD always use zlib compression level 6. This patch changes it to use 1 for -O0, -O1 and 6 for -O2. It fixes https://bugs.llvm.org/show_bug.cgi?id=44089. There was also a thread in llvm-dev on this topic: https://lists.llvm.org/pipermail/llvm-dev/2018-August/125020.html Here is a table with results of building clang mentioned there: ``` Level Time Size 0 0m17.128s 2045081496 Z_NO_COMPRESSION 1 0m31.471s 922618584 Z_BEST_SPEED 2 0m32.659s 903642376 3 0m36.749s 890805856 4 0m41.532s 876697184 5 0m48.383s 862778576 6 1m3.176s 855251640 Z_DEFAULT_COMPRESSION 7 1m15.335s 853755920 8 2m0.561s 852497560 9 2m33.972s 852397408 Z_BEST_COMPRESSION ``` It shows that it is probably not reasonable to use values greater than 6. Differential revision: https://reviews.llvm.org/D70658
* [ELF] Support input section description .rel[a].dyn in /DISCARD/Fangrui Song2019-11-251-4/+15
| | | | | | Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D70695
* [ELF][test] Clean up some thunk testsFangrui Song2019-11-236-85/+85
| | | | | Use llvm-objdump --no-show-raw-insn --print-imm-hex Prefer generic aarch64 triple to linux/freebsd specific triples.
* [ELF] Error if -Ttext-segment is specifiedFangrui Song2019-11-212-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In GNU ld, -Ttext sets the address of the .text section and -Ttext-segment sets the address of the text segment (RX). gold only supports the -Ttext-segment semantic and treats -Ttext as an alias for -Ttext-segment. lld only supports the -Ttext semantic and treats -Ttext-segment as an alias for -Ttext. The text segment will be assigned to an address less than the specified -Ttext-segment value. This patch drops the -Ttext-segment alias. The text segment is traditionally the first segment. Users who specify -Ttext-segment may actually want to specify --image-base, the lld way to express this. Unfortunately currently this is supported by GNU ld's COFF port but not by its ELF port. gold does not support this option. With -z separate-code, the behavior of GNU ld -Ttext-segment is weird (see https://sourceware.org/bugzilla/show_bug.cgi?id=25207) rL289827 introduced the alias for linking qemu's non-pie user mode binaries. As explained previously, this actually assigns the text segment to an address less than 0x60000000. I feel that a better fix is on the qemu side: https://lists.nongnu.org/archive/html/qemu-devel/2019-11/msg02480.html Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D70468
* Ignore R_MIPS_JALR relocations against non-function symbolsAlex Richardson2019-11-201-0/+53
| | | | | | | | | | | | | | | | | | | | Summary: Current versions of clang would erroneously emit this relocation not only against functions (loaded from the GOT) but also against data symbols (e.g. a table of function pointers). LLD was then changing this into a branch-and-link instruction, causing the program to jump to the data symbol at run time. I discovered this problem when attempting to boot MIPS64 FreeBSD after updating the to the latest upstream master. Reviewers: atanasyan, jrtc27, espindola Reviewed By: atanasyan Subscribers: emaste, sdardis, krytarowski, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70406
* [llvm-readobj/llvm-readelf] - Improve dumping of versioning sections.Georgii Rymar2019-11-204-16/+35
| | | | | | | | | | | | | Our elf-versioninfo.test is not perfect. It does not properly test how flags are dumped and also we have a bug: they are dumped as enums in LLVM style now, i.e not dumped properly. GNU style uses a `versionFlagToString` method to build a string from flags which seems is consistent with GNU readelf. In this patch I fixed the issues mentioned. Differential revision: https://reviews.llvm.org/D70399
* [ELF] Improve --gc-sections compatibility with GNU ld regarding section groupsFangrui Song2019-11-192-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on D70020 by serge-sans-paille. The ELF spec says: > Furthermore, there may be internal references among these sections that would not make sense if one of the sections were removed or replaced by a duplicate from another object. Therefore, such groups must be included or omitted from the linked object as a unit. A section cannot be a member of more than one group. GNU ld has 2 behaviors that we don't have: - Group members (nextInSectionGroup != nullptr) are subject to garbage collection. This includes non-SHF_ALLOC SHT_NOTE sections. In particular, discarding non-SHF_ALLOC SHT_NOTE sections is an expected behavior by the Annobin project. See https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/ for more information. - Groups members are retained or discarded as a unit. Members may have internal references that are not expressed as SHF_LINK_ORDER, relocations, etc. It seems that we should be more conservative here: if a section is marked live, mark all the other member within the group. Both behaviors are reasonable. This patch implements them. A new field InputSectionBase::nextInSectionGroup tracks the next member within a group. on ELF64, this increases sizeof(InputSectionBase) froms 144 to 152. InputSectionBase::dependentSections tracks section dependencies, which is used by both --gc-sections and /DISCARD/. We can't overload it for the "next member" semantic, because we should allow /DISCARD/ to discard sections independent of --gc-sections (GNU ld behavior). This behavior may be reasonably used by `/DISCARD/ : { *(.ARM.exidx*) }` or `/DISCARD/ : { *(.note*) }` (new test `linkerscript/discard-group.s`). Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D70146
* [COFF] Don't error if the only inputs are from /wholearchive:Reid Kleckner2019-11-153-1/+13
| | | | | | Fixes PR43744 Differential Revision: https://reviews.llvm.org/D69968
* Warn on /align if used without /driverRui Ueyama2019-11-141-0/+13
| | | | | | | /align is not supposed to be used without /driver, so it makes sense to warn if only /align is passed. MSVC link.exe warns on this too. Differential Revision: https://reviews.llvm.org/D70163
* Implement /driver, /driver:wdm and /driver:uponlyRui Ueyama2019-11-141-0/+98
| | | | | | | | This patch implements /driver, /driver:wdm and /driver:uponly as described in https://docs.microsoft.com/en-us/cpp/build/reference/driver-windows-nt-kernel-mode-driver?view=vs-2019. Differential Revision: https://reviews.llvm.org/D70162
* [LLD] [COFF] Fix automatically importing data symbols from DLLs with LTOMartin Storsjö2019-11-131-0/+28
| | | | | | | | | | | | | | | | This broke in 51dcb292cc002, "[lld-link] diagnose undefined symbols before LTO when possible" (very soon after the 9.0 branch, so luckily the 9.0 release is unaffected). The code for loading objects we believe might be needed for autoimport (loadMinGWAutomaticImports()) does run before the new reportUnresolvable() function, but it had a condition to only operate on symbols from regular object files. This condition came from resolveRemainingUndefines(), but as loadMinGWAutomaticImports() now has to operate before the LTO, it has to operate on undefineds from LTO objects as well. Differential Revision: https://reviews.llvm.org/D70166
* [MC] Emit unused undefined symbol even if its binding is not setFangrui Song2019-11-082-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | Recommit r373168, which was reverted by r373242. This actually exposed a boringssl bug which has been fixed for more than one month. For the following two cases, we currently suppress the symbols. This patch emits them (compatible with GNU as). * `test2_a = undef`: if `undef` is otherwise unused. * `.hidden hidden`: if `hidden` is unused. This is the main point of the patch, because omitting the symbol would cause a linker semantic difference. It causes a behavior change that is not compatible with GNU as: .weakref foo1, bar1 When neither foo1 nor bar1 is used, we now emit bar1, which is arguably more consistent. Another change is that we will emit .TOC. for .TOC.@tocbase . For this directive, suppressing .TOC. can be seen as a size optimization, but we choose to drop it for simplicity and consistency.
OpenPOWER on IntegriCloud