summaryrefslogtreecommitdiffstats
path: root/lld
Commit message (Collapse)AuthorAgeFilesLines
...
* Port r363962 to COFF: Deduplicate undefined symbol diagnosticsNico Weber2019-06-254-11/+116
| | | | | | | | | | | | | | | | | | lld/coff already deduplicated undefined symbols on a TU level: It would group all references to a symbol from a single TU. This makes it so that references from all TUs to a single symbol are grouped together. Since lld/coff almost did what I thought it did already, the patch is much smaller than the elf version. The only not local change is that getSymbolLocations() now returns a vector<string> instead of a string, so that the undefined symbol reporting code can know how many references to a symbol exist in a given TU. Fixes PR42260 for lld/coff. Differential Revision: https://reviews.llvm.org/D63646 llvm-svn: 364285
* Fix an issue that common symbols are not internalized under some condition.Rui Ueyama2019-06-252-3/+24
| | | | | | | | | | | | | | | | | | | | r360841 introduced CommonSymbol class. An unintended behavioral change introduced by that change was that common symbols are not internalized by LTO under some condition. This patch fixes that issue. The issue occurred under the following condition: 1. There exists a common symbol 2. At least one DSO is given to lld or -pie is used If the above conditions are met, Symbol::includeInDynsym() returned a wrong value for a common symbol. Fixes https://bugs.llvm.org/show_bug.cgi?id=41978 Differential Revision: https://reviews.llvm.org/D63752 llvm-svn: 364273
* [ELF][PPC][X86] Use [-2**(n-1), 2**n) to check overflows for R_PPC_ADDR16, ↵Fangrui Song2019-06-2424-114/+110
| | | | | | | | | | | | | | | | | | | | | R_PPC64_ADDR{16,32}, R_X86_64_{8,16} Similar to R_AARCH64_ABS32, R_PPC64_ADDR32 can represent either a signed value or unsigned value, thus we should use `[-2**(n-1), 2**n)` instead of `[-2**(n-1), 2**(n-1))` to check overflows. The issue manifests as a bogus linker error when linking the powerpc64le Linux kernel. The new behavior is compatible with ld.bfd's complain_overflow_bitfield. The upper bound of the error message is not correct. Fix it as well. The changes to R_PPC_ADDR16, R_PPC64_ADDR16, R_X86_64_8 and R_X86_64_16 are similar. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63690 llvm-svn: 364164
* lld/elf: Deduplicate undefined symbol diagnosticsNico Weber2019-06-205-32/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before: ``` ld.lld: error: undefined symbol: f() >>> referenced by test.cc:3 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(g()) ld.lld: error: undefined symbol: f() >>> referenced by test.cc:4 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(h()) ld.lld: error: undefined symbol: f() >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(j()) ld.lld: error: undefined symbol: k() >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-9c0808.o:(j()) ld.lld: error: undefined symbol: f() >>> referenced by test2.cc:2 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test2-07b391.o:(asdf()) clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` Now: ``` ld.lld: error: undefined symbol: f() >>> referenced by test.cc:3 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(g()) >>> referenced by test.cc:4 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(h()) >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(j()) >>> referenced by test2.cc:2 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test2-6bdb24.o:(asdf()) ld.lld: error: undefined symbol: k() >>> referenced by test.cc:5 >>> /var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/test-0e07ba.o:(j()) clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` If there are more than 10 references to an undefined symbol, only the first 10 are printed. Fixes PR42260. Differential Revision: https://reviews.llvm.org/D63344 llvm-svn: 363962
* [ELF][ARM][AARCH64][MIPS][PPC] Simplify the logic to create R_*_RELATIVE for ↵Fangrui Song2019-06-2013-92/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | absolute relocation types in writable sections Summary: Our rule to create R_*_RELATIVE for absolute relocation types were loose. D63121 made it stricter but it failed to create R_*_RELATIVE for R_ARM_TARGET1 and R_PPC64_TOC. rLLD363236 worked around that by reinstating the original behavior for ARM and PPC64. This patch is an attempt to simplify the logic. Note, in ld.bfd, R_ARM_TARGET2 --target2=abs also creates R_ARM_RELATIVE. This seems a very uncommon scenario (moreover, --target2=got-rel is the default), so I do not implement any logic related to it. Also, delete R_AARCH64_ABS32 from AArch64::getDynRel. We don't have working ILP32 support yet. Allowing it would create an incorrect R_AARCH64_RELATIVE. For MIPS, the (if SymbolRel, then RelativeRel) code is to keep its behavior unchanged. Note, in ppc64-abs64-dyn.s, R_PPC64_TOC gets an incorrect addend because computeAddend() doesn't compute the correct address. We seem to have the wrong behavior for a long time. The important thing seems that a dynamic relocation R_PPC64_TOC should not be created as the dynamic loader will error R_PPC64_TOC is not supported. Reviewers: atanasyan, grimar, peter.smith, ruiu, sfertile, espindola Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63383 llvm-svn: 363928
* [ELF][ARM] Merge handleARMTlsRelocation() into handleTlsRelocation()Fangrui Song2019-06-202-68/+38
| | | | | | | | | | | | | | | | | | | | | | | ARM and RISC-V do not support TLS relaxations. However, for General Dynamic and Local Dynamic models, if we are producing an executable and the symbol is non-preemptable, we know it must be defined and the R_ARM_TLS_DTPMOD32/R_RISCV_TLS_DTPMOD{32,64} dynamic relocation can be omitted because it is always 1. This may be necessary for static linking as DTPMOD may not be expected at load time. Merge handleARMTlsRelocation() into handleTlsRelocation(). This requires more logic to R_TLSGD_PC and R_TLSLD_PC. Because we use SymbolicRel to resolve the relocation at link time, R_ARM_TLS_DTPMOD32 can be deleted from relocateOne(). It cannot be used as a static relocation type. As a bonus, the additional logic in R_TLSGD_PC code can be shared by the TLS support for RISC-V (D63220). Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63333 llvm-svn: 363927
* [llvm-readobj] Match GNU output for DT_RPATH and DT_RUNPATH when dumping ↵Yuanfang Chen2019-06-193-4/+4
| | | | | | | | | | | | | | dynamic symbol table. Reviewers: jhenderson, grimar, MaskRay, rupprecht, espindola Subscribers: emaste, nemanjai, arichardson, kbarton, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63347 llvm-svn: 363868
* [PDB] Ignore .debug$S subsections with high bit setReid Kleckner2019-06-182-0/+19
| | | | | | | | Some versions of the Visual C++ 2015 runtime have line tables with the subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to be DEBUG_S_IGNORE. This appears to implement the intended behavior. llvm-svn: 363724
* [Remarks] Extend -fsave-optimization-record to specify the formatFrancis Visoiu Mistrih2019-06-175-0/+8
| | | | | | | | | Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
* [llvm-objdump] Use %08 instead of %016 to print leading addresses for 32-bit ↵Fangrui Song2019-06-175-16/+16
| | | | | | | | | | binaries Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D63398 llvm-svn: 363539
* Include the file in the new unknown codeview subsection warningReid Kleckner2019-06-141-1/+1
| | | | llvm-svn: 363466
* [COFF] Strip section name suffix from mingw comdatsMartin Storsjo2019-06-142-1/+46
| | | | | | | | This is the second part of the fix for PR42217. Differential Revision: https://reviews.llvm.org/D63352 llvm-svn: 363457
* [COFF] Handle .eh_frame$symbol as associative comdat for MinGWMartin Storsjo2019-06-142-3/+43
| | | | | | | | | | | | | This matches how it is done for .xdata and .pdata already. On i386, the symbol name in the section name suffix does not contain the extra underscore prefix. This is one part of a fix for PR42217. Differential Revision: https://reviews.llvm.org/D63350 llvm-svn: 363456
* [MinGW] Support the --subsystem=val option in joined formMartin Storsjo2019-06-142-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D63250 llvm-svn: 363433
* [MinGW] Support the --{major,minor}-{os,subsystem}-version optionsMartin Storsjo2019-06-143-1/+54
| | | | | | | | This fixes PR42218. Differential Revision: https://reviews.llvm.org/D63249 llvm-svn: 363432
* [COFF] Allow setting subsystem versions while inferring the subsystem type ↵Martin Storsjo2019-06-143-2/+17
| | | | | | | | implicitly Differential Revision: https://reviews.llvm.org/D63248 llvm-svn: 363431
* Wrap a test to 80 columnsNico Weber2019-06-141-2/+2
| | | | llvm-svn: 363421
* Remove two unused parametersNico Weber2019-06-141-4/+2
| | | | llvm-svn: 363419
* [LLD][ELF] - Fix test case after r363401George Rimar2019-06-141-1/+1
| | | | llvm-svn: 363402
* [ELF] Don't emit dynamic relocations with weak undef in writable sectionsFangrui Song2019-06-142-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In processRelocAux(), our handling of 1) link-time constant and 2) weak undef is the same, so put them together to simplify the logic. This moves the weak undef code around. The result is that: in a writable section (or -z notext), we will no longer emit dynamic relocations for weak undefined symbols. The new behavior seems to match GNU linkers, and improves consistency with the case of a readonly section. The condition `!Config->Shared` was there probably because it is common for a -shared link not to specify full dependencies. Keep it now but we may revisit the decision in the future. gABI says: > The behavior of weak symbols in areas not specified by this document is > implementation defined. Weak symbols are intended primarily for use in > system software. Applications using weak symbols are unreliable since > changes in the runtime environment might cause the execution to fail. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63003 llvm-svn: 363399
* Revert r363395.George Rimar2019-06-141-1/+1
| | | | | | It will not work because of r363394. llvm-svn: 363398
* lld/coff: slightly simplify ImportFile::parse()Nico Weber2019-06-141-2/+1
| | | | llvm-svn: 363397
* Add --undefined-glob which is an --undefined with wildcard pattern matchRui Ueyama2019-06-144-11/+112
| | | | | | | | | | | | | | | | | | | | | This patch adds new command line option `--undefined-glob` to lld. That option is a variant of `--undefined` but accepts wildcard patterns so that all symbols that match with a given pattern are handled as if they were given by `-u`. `-u foo` is to force resolve symbol foo if foo is not a defined symbol and there's a static archive that contains a definition of symbol foo. Now, you can specify a wildcard pattern as an argument for `--undefined-glob`. So, if you want to include all JNI symbols (which start with "Java_"), you can do that by passing `--undefined-glob "Java_*"` to the linker, for example. In this patch, I use the same glob pattern matcher as the version script processor is using, so it does not only support `*` but also `?` and `[...]`. Differential Revision: https://reviews.llvm.org/D63244 llvm-svn: 363396
* [ELF] - Attemp to fix BB.George Rimar2019-06-141-1/+1
| | | | | | | | Seems section has a wrong type. http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/28 llvm-svn: 363395
* [ELF][RISCV] Create dummy .sdata for __global_pointer$ if .sdata does not existFangrui Song2019-06-147-3/+93
| | | | | | | | | | | | | | | | | | | | | | | | | If .sdata is absent, linker synthesized __global_pointer$ gets a section index of SHN_ABS. (ld.bfd has a similar issue: binutils PR24678) Scrt1.o may use `lla gp, __global_pointer$` to reference the symbol PC relatively. In -pie/-shared mode, lld complains if a PC relative relocation references an absolute symbol (SHN_ABS) but ld.bfd doesn't: ld.lld: error: relocation R_RISCV_PCREL_HI20 cannot refer to lute symbol: __global_pointer$ Let the reference of __global_pointer$ to force creation of .sdata to fix the problem. This is similar to _GLOBAL_OFFSET_TABLE_, which forces creation of .got or .got.plt . Also, change the visibility from STV_HIDDEN to STV_DEFAULT and don't define the symbol for -shared. This matches ld.bfd, though I don't understand why it uses STV_DEFAULT. Reviewed By: ruiu, jrtc27 Differential Revision: https://reviews.llvm.org/D63132 llvm-svn: 363351
* [lld][ELF] Add tests for bad subsection length in .ARM.attributesEugene Leviant2019-06-132-0/+16
| | | | | | Differential revision: https://reviews.llvm.org/D63191 llvm-svn: 363261
* [ELF] Loosen the condition that changes absolute relocation types to ↵Fangrui Song2019-06-131-1/+7
| | | | | | | | relative relocations for ARM and PPC64 Try fixing build bots after D63121 llvm-svn: 363236
* [lld] Fix type server merging with PDBs without IPI streamReid Kleckner2019-06-124-13/+39
| | | | | | | | | | | | | | | PDBs may not necessarily contain an IPI stream. Handle this case gracefully. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev, with a small simplification Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63178 llvm-svn: 363213
* [lld] Allow unrecognized signatures in debug sectionsReid Kleckner2019-06-122-4/+33
| | | | | | | | | | | | | | | | | | An unrecognized signature (magic) at the beginning of a debug section should not be a fatal error; it only means that the debug information is in a format that is not supported by LLD. This can be due to it being in CodeView versions 3 or earlier. These can occur in old import libraries from legacy SDKs. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev! Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63177 llvm-svn: 363212
* Share /machine: handling code with llvm-cvtres tooNico Weber2019-06-122-2/+3
| | | | | | | | | | | | | | r363016 let lld-link and llvm-lib share the /machine: parsing code. This lets llvm-cvtres share it as well. Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't need llvm-lib's dependencies on BinaryFormat and BitReader) and I couldn't find a good place to put this code. Since it's just a few lines, put it in lib/Object for now. Differential Revision: https://reviews.llvm.org/D63120 llvm-svn: 363144
* [ELF][RISCV] Treat R_RISCV_{ADD,SET,SUB}* as link-time constantsFangrui Song2019-06-125-2/+45
| | | | | | | | | | | | | | | | | | | | | | | R_RISCV_{ADD,SET,SUB}* are used for local label computation. Add a new RelExpr member R_RISCV_ADD to represent them. R_RISCV_ADD is treated as a link-time constant because otherwise R_RISCV_{ADD,SET,SUB}* are not allowed in -pie/-shared mode. In glibc Scrt1.o, .rela.eh_frame contains such relocations. Because .eh_frame is not writable, we get this error: ld.lld: error: can't create dynamic relocation R_RISCV_ADD32 against symbol: .L0 in readonly segment; recompil object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output >>> defined in ..../riscv64-linux-gnu/lib/Scrt1.o With D63076 and this patch, I can run -pie/-shared programs linked against glibc. Note llvm-mc cannot currently produce R_RISCV_SET* so they are not tested. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63183 llvm-svn: 363128
* [ELF][PPC64] Don't report "relocation refers to a discarded section" for .tocFangrui Song2019-06-123-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: clang (as of 2019-06-12) / gcc (as of 8.2.1) PPC64 may emit a .rela.toc which references an embedded switch table in a discarded .rodata/.text section. The .toc and the .rela.toc are incorrectly not placed in the comdat. Technically a relocation from outside the group is not allowed by the ELF spec: > A symbol table entry with STB_LOCAL binding that is defined relative > to one of a group's sections, and that is contained in a symbol table > section that is not part of the group, must be discarded if the group > members are discarded. References to this symbol table entry from > outside the group are not allowed. Don't report errors to work around the bug. This should fix the ppc64le-lld-multistage-test bot while linking llvm-tblgen: ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o >>> referenced by CodeGenRegisters.cpp >>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0) Some other PPC specific sections may have similar problems. We can blacklist more section names when problems occur. // A simple program that reproduces the bug. // Note .rela.toc (outside the group) references a section symbol (STB_LOCAL) in a group. void puts(const char *); struct A { void foo(int a) { switch (a) { case 0: puts("0"); break; case 1: puts("1"); puts("1"); break; case 2: puts("2"); break; case 3: puts("3"); puts("4"); break; case 4: puts("4"); break; case 5: puts("5"); puts("5"); break; case 6: puts("6"); break; } } int a; }; void foo(A x) { x.foo(x.a); } Reviewers: ruiu, sfertile, espindola Reviewed By: ruiu Subscribers: emaste, nemanjai, arichardson, kbarton, jsji, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63182 llvm-svn: 363126
* Revert "Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16"Fangrui Song2019-06-122-30/+31
| | | | | | | | | | | | | | | This reverts commit r363060 and restores r362867. r362867 is innocent. The ppc64le-lld-multistage-test bot failure was due to a clang/gcc .toc bug: ld.lld: error: relocation refers to a discarded section: .rodata._ZNK4llvm3MVT13getSizeInBitsEv >>> defined in utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o >>> referenced by CodeGenRegisters.cpp >>> utils/TableGen/CMakeFiles/llvm-tblgen.dir/CodeGenRegisters.cpp.o:(.toc+0x0) It will be worked around by D63182. llvm-svn: 363124
* Deduplicate S_CONSTANTs in LLD.Amy Huang2019-06-113-0/+446
| | | | | | | | | | | | | | Summary: Deduplicate S_CONSTANTS when linking, if they have the same value. Reviewers: rnk Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D63151 llvm-svn: 363089
* lld-link: Reject more than one resource .obj fileNico Weber2019-06-116-5/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Users are exepcted to pass all .res files to the linker, which then merges all the resource in all .res files into a tree structure and then converts the final tree structure to a .obj file with .rsrc$01 and .rsrc$02 sections and then links that. If the user instead passes several .obj files containing such resources, the correct thing to do would be to have custom code to merge the trees in the resource sections instead of doing normal section merging -- but link.exe rejects if multiple resource obj files are passed in with LNK4078, so let lld-link do that too instead of silently writing broken .rsrc sections in that case. The only real way to run into this is if users manually convert .res files to .obj files by running cvtres and then handing the resulting .obj files to lld-link instead, which in practice likely never happens. (lld-link is slightly stricter than link.exe now: If link.exe is passed one .obj file created by cvtres, and a .res file, for some reason it just emits a warning instead of an error and outputs strange looking data. lld-link now errors out on mixed input like this.) One way users could accidentally run into this is the following scenario: If a .res file is passed to lib.exe, then lib.exe calls cvtres.exe on the .res file before putting it in the output .lib. (llvm-lib currently doesn't do this.) link.exe's /wholearchive seems to only add obj files referenced from the static library index, but lld-link current really adds all files in the archive. So if lld-link /wholearchive is used with .lib files produced by lib.exe and .res files were among the files handed to lib.exe, we previously silently produced invalid output, but now we error out. link.exe's /wholearchive semantics on the other hand mean that it wouldn't load the resource object files from the .lib file at all. Since this scenario is probably still an unlikely corner case, the difference in behavior here seems fine -- and lld-link might have to change to use link.exe's /wholearchive semantics in the future anyways. Vaguely related to PR42180. Differential Revision: https://reviews.llvm.org/D63109 llvm-svn: 363078
* [ELF][RISCV] Add R_RISCV_PC_INDIRECT to isRelExpr()Fangrui Song2019-06-112-17/+22
| | | | | | | | | | | | | So that R_RISCV_PCREL_LO12_[IS] are considered as link-time constants in -pie mode, otherwise there are bogus errors: ld.lld: error: can't create dynamic relocation R_RISCV_PCREL_LO12_I against symbol: .L0 in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63123 llvm-svn: 363064
* Revert r362867: [ELF][PPC] Simplify {read,write}FromHalf16Rui Ueyama2019-06-112-31/+30
| | | | | | | This reverts commit r362867 since it seems to have broken ppc64le-lld-multistage-test bot. llvm-svn: 363060
* [ELF] Make the rule to create relative relocations in a writable section ↵Fangrui Song2019-06-1118-28/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | stricter The current rule is loose: `!Sym.IsPreemptible || Expr == R_GOT`. When the symbol is non-preemptable, this allows absolute relocation types with smaller numbers of bits, e.g. R_X86_64_{8,16,32}. They are disallowed by ld.bfd and gold, e.g. ld.bfd: a.o: relocation R_X86_64_8 against `.text' can not be used when making a shared object; recompile with -fPIC This patch: a) Add TargetInfo::SymbolicRel to represent relocation types that resolve to a symbol value (e.g. R_AARCH_ABS64, R_386_32, R_X86_64_64). As a side benefit, we currently (ab)use GotRel (R_*_GLOB_DAT) to resolve GOT slots that are link-time constants. Since we now use Target->SymbolRel to do the job, we can remove R_*_GLOB_DAT from relocateOne() for all targets. R_*_GLOB_DAT cannot be used as static relocation types. b) Change the condition to `!Sym.IsPreemptible && Type != Target->SymbolicRel || Expr == R_GOT`. Some tests are caught by the improved error checking (ld.bfd/gold also issue errors on them). Many misuse .long where .quad should be used instead. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63121 llvm-svn: 363059
* Let writeWindowsResourceCOFF() take a TimeStamp parameterNico Weber2019-06-111-1/+2
| | | | | | | | | | | | | | | | | | | For lld, pass in Config->Timestamp (which is set based on lld's /timestamp: and /Brepro flags). Since the writeWindowsResourceCOFF() data is only used in-memory by LLD and the obj's timestamp isn't used for anything in the output, this doesn't change behavior. For llvm-cvtres, add an optional /timestamp: parameter, and use the current behavior of calling time() if the parameter is not passed in. This doesn't really change observable behavior (unless someone passes /timestamp: to llvm-cvtres, which wasn't possible before), but it removes the last unqualified call to time() from llvm/lib, which seems like a good thing. Differential Revision: https://reviews.llvm.org/D63116 llvm-svn: 363050
* ELF: Don't process the partition end marker during combineEhSections().Peter Collingbourne2019-06-111-2/+4
| | | | | | | | | | Otherwise the getPartition() accessor may return an OOB pointer. Found using _GLIBCXX_DEBUG. The error is benign (we never dereference the pointer for the end marker) so this wasn't caught by e.g. the sanitizer bots. llvm-svn: 363026
* Fix -DBUILD_SHARED_LIBS=on build after r362977Fangrui Song2019-06-111-0/+1
| | | | | | | The executable has an undefined reference to lld::Saver, the library should be explicitly linked. llvm-svn: 363023
* Wrap comment to 80 columnsNico Weber2019-06-111-3/+3
| | | | llvm-svn: 363017
* llvm-lib: Implement /machine: argumentNico Weber2019-06-114-33/+5
| | | | | | | | | | And share some code with lld-link. While here, also add a FIXME about PR42180 and merge r360150 to llvm-lib. Differential Revision: https://reviews.llvm.org/D63021 llvm-svn: 363016
* [LLD] Change FileCheck output file pattern to a temporary fileTim Shen2019-06-101-3/+3
| | | | | | | The previous name "%lib" doesn't trigger any actual replacement. It creates the file "./tools/lld/test/ELF/%lib.o" in the test directory. llvm-svn: 362988
* [Driver] Look for -m in response files as wellMartin Storsjo2019-06-103-3/+37
| | | | | | | | | | Also expand response files in the MinGW driver. This should fix PR42135. Differential Revision: https://reviews.llvm.org/D63024 llvm-svn: 362977
* [LLD][COFF] Fix missing MergeChunk::Instances cleanup in COFF::link()Rui Ueyama2019-06-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Erik McClure with a modification to rebase to HEAD. When calling `COFF::link()` with `CanExitEarly` set to `false`, the function needs to clean up several global variable caches to ensure that the next invocation of the function starts from a clean slate. The `MergeChunk::Instances` cache is missing from this cleanup code, and as a result will create nondeterministic memory access errors and sometimes infinite loops due to invalid memory being referenced on the next call to `COFF::link()`. This fix simply clears `MergeChunk::Instances` before exiting the function. An additional review of the COFF library was made to try and find any other missing global caches, but I was unable to find any other than `MergeChunk`. Someone more familiar with the global variables might want to do their own check. This fix was made to support inNative <https://github.com/innative-sdk/innative>'s `.wast` script compiler, which must build multiple incremental builds. It relies on statically linking LLD because the entire compiler must be a single statically embeddable library, thus preventing it from being able to call LLD as a new process. Differential Revision: https://reviews.llvm.org/D63042 llvm-svn: 362930
* [COFF][X86] Add REQUIRES: x86 to a couple of testsPeter Smith2019-06-102-0/+2
| | | | | | | | | Fix buildbot failure on native AArch64 buildbot that does not have X86 backend compiled in. Differential Revision: https://reviews.llvm.org/D63071 llvm-svn: 362926
* [ELF][RISCV] Parse BFD names elf{32,64}-littleriscvFangrui Song2019-06-102-0/+76
| | | | | | | | | | e.g. glibc libc.so on riscv64 uses `OUTPUT_FORMAT(elf64-littleriscv)`. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D63070 llvm-svn: 362922
* [ELF] [PPC] Fix a typo from SVN r362721Martin Storsjo2019-06-081-1/+1
| | | | | | | Apparently no test covers this exact codepath, but GCC produced a warning about it. llvm-svn: 362883
* [MinGW] Support the -u/--undefined option.Martin Storsjo2019-06-083-0/+9
| | | | | | | | | | | | This is implemented by the lld-link option -include:, just like --require-defined. Contrary to --require-defined, the -u/--undefined option allows the symbol to remain undefined in the end. This should fix PR42121. Differential Revision: https://reviews.llvm.org/D62876 llvm-svn: 362882
OpenPOWER on IntegriCloud