summaryrefslogtreecommitdiffstats
path: root/lld/ELF
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF] Delete redundant isLive() check. NFCFangrui Song2019-12-151-2/+0
|
* Revert "[ELF] Allow getErrPlace() to work before Out::bufferStart is set"Vlad Tsyrklevich2019-12-131-4/+4
| | | | | | 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-1/+18
| | | | | | | | | | | | | | | | | | 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-4/+4
| | | | | | | | | | | | | | | | | | 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-138-66/+12
|
* temporaryRui Ueyama2019-12-138-12/+66
|
* [ELF] Add a comment to handleSectionGroup(). NFCFangrui Song2019-12-121-0/+2
| | | | | | | | Apply suggestion in https://reviews.llvm.org/D71157#1780834 Reviewed By: grimar, ruiu Differential Revision: https://reviews.llvm.org/D71388
* [ELF][AArch64] Rename --force-bti to -z force-bti and --pac-plt to -z pac-pltFangrui Song2019-12-112-20/+15
| | | | | | | | | | | | | | | | | | | 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-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-112-0/+8
| | | | | | | | | | | | | 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] Move a computeIsPreemptible() pass into ICF. NFCFangrui Song2019-12-102-5/+6
| | | | | | | | Address post-commit review for D71163. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D71326
* [ELF] --icf: do not fold preemptible symbolsFangrui Song2019-12-105-31/+42
| | | | | | | | | | | | | | | 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-101-20/+38
| | | | | | | | | | | | | | | | | | | 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
* [ELF][PPC64] Support long branch thunks with addendsFangrui Song2019-12-057-49/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF][PPC64] Don't copy ppc64BranchltIndex in replaceWithDefinedFangrui Song2019-12-051-1/+0
| | | | | | | replaceWithDefined is used by canonical PLT and copy relocations, which imply that the symbol is preemptable. ppc64BranchltIndex is only used by non-preemptable cases, and it can only be the default value in replaceWithDefined.
* [LLD][ELF][AArch64] .note.gnu.property sections should have alignment 8Peter Smith2019-12-051-2/+2
| | | | | | | | | | | 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-051-0/+3
| | | | | | | | | | 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-0211-51/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ELF][ARM] Add getPCBias()Fangrui Song2019-11-271-2/+18
| | | | | | | | | | | | | | ThunkCreator::getThunk and ThunkCreator::normalizeExistingThunk currently assume that the implicit addends are -8 for ARM and -4 for Thumb. In D70637, ThunkCreator::getThunk will need to take care of the relocation addend explicitly. Add the utility function getPCBias() as a prerequisite so that the getThunk change in D70637 can be more general. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D70690
* [ELF] Add a corrector for case mismatch problemsFangrui Song2019-11-261-0/+8
| | | | | | Reviewed By: grimar, peter.smith Differential Revision: https://reviews.llvm.org/D70506
* [ELF] Replace SymbolTable::forEachSymbol with iterator_range symbols()Fangrui Song2019-11-266-34/+34
| | | | | | | | | | | | | | D62381 introduced forEachSymbol(). It seems that many call sites cannot be parallelized because the body shared some states. Replace forEachSymbol with iterator_range<filter_iterator<...>> symbols() to simplify code and improve debuggability (std::function calls take some frames). It also allows us to use early return to simplify code added in D69650. Reviewed By: grimar Differential Revision: https://reviews.llvm.org/D70505
* [LLD][ELF] - Make compression level be dependent on -On.Georgii Rymar2019-11-261-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D70695
* [ELF] Delete unused Configuration::zExecstack after D56554Fangrui Song2019-11-252-2/+0
|
* [ELF] Error if -Ttext-segment is specifiedFangrui Song2019-11-212-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* LLD: Don't use the stderrOS stream in link before it's reassigned.James Y Knight2019-11-212-8/+8
| | | | | | | | | | | | | | | | Remove the lld::enableColors function, as it just obscures which stream it's affecting, and replace with explicit calls to the stream's enable_colors. Also, assign the stderrOS and stdoutOS globals first in link function, just to ensure nothing might use them. (Either change individually fixes the issue of using the old stream, but both together seems best.) Follow-up to b11386f9be9b2dc7276a758d64f66833da10bdea. Differential Revision: https://reviews.llvm.org/D70492
* Ignore R_MIPS_JALR relocations against non-function symbolsAlex Richardson2019-11-201-0/+11
| | | | | | | | | | | | | | | | | | | | 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
* [ELF] Disallow out-of-range section group indices after D70146Fangrui Song2019-11-191-0/+2
| | | | | Exposed by invalid/sht-group-wrong-section.test http://45.33.8.238/win/2613/step_9.txt
* [ELF] Improve --gc-sections compatibility with GNU ld regarding section groupsFangrui Song2019-11-193-2/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make it possible to redirect not only errs() but also outs()Rui Ueyama2019-11-183-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change is for those who use lld as a library. Context: https://reviews.llvm.org/D70287 This patch adds a new parmeter to lld::*::link() so that we can pass an raw_ostream object representing stdout. Previously, lld::*::link() took only an stderr object. Justification for making stdoutOS and stderrOS mandatory: I wanted to make link() functions to take stdout and stderr in that order. However, if we change the function signature from bool link(ArrayRef<const char *> args, bool canExitEarly, raw_ostream &stderrOS = llvm::errs()); to bool link(ArrayRef<const char *> args, bool canExitEarly, raw_ostream &stdoutOS = llvm::outs(), raw_ostream &stderrOS = llvm::errs()); , then the meaning of existing code that passes stderrOS silently changes (stderrOS would be interpreted as stdoutOS). So, I chose to make existing code not to compile, so that developers can fix their code. Differential Revision: https://reviews.llvm.org/D70292
* [ELF] Fix lld build on Windows/MinGWAyke van Laethem2019-11-161-14/+14
| | | | | | | | | | | | | | | | | | The patch in https://reviews.llvm.org/D64077 causes a build failure because both the Defined and SharedSymbol classes are bigger than 80 bytes on MinGW 8. This patch fixes this build failure by changing the type of the bitfields. It is a similar change to the bitfield changes in https://reviews.llvm.org/D64238, but instead of changing to bool I decided to use uint8_t because one of the bitfields takes up two bits instead of one. Note: the patch is slightly different from the one reviewed in Phabricator, but it is a trivial change to align it with LLVM master instead of LLVM 9. Also, it passes all lld tests. Differential Revision: https://reviews.llvm.org/D70266
* Forward declare the DWARFCache to avoid including LLVM DWARF detailsReid Kleckner2019-11-142-1/+3
| | | | | LLD's DWARF.h header leaks a lot of LLVM DWARF includes that LLD doesn't need. For Chunks.cpp, I see a compile time decrease of 3.1s to 2.7s.
* [ELF] Fix stack-use-after-scope after D69592 and 69650Fangrui Song2019-11-081-2/+4
|
* [ELF] Suggest extern "C" when the definition is mangled while an undefined ↵Fangrui Song2019-11-081-4/+36
| | | | | | | | | | | | | | | | | | | | reference is not The definition may be mangled while an undefined reference is not. This may come up when (1) the reference is from a C file or (2) the definition misses an extern "C". (2) is more common. Suggest an arbitrary mangled name that matches the undefined reference, if such a definition exists. ld.lld: error: undefined symbol: foo >>> referenced by a.o:(.text+0x1) >>> did you mean to declare foo(int) as extern "C"? >>> defined in: a1.o Reviewed By: dblaikie, ruiu Differential Revision: https://reviews.llvm.org/D69650
* [ELF] Suggest extern "C" when an undefined reference is mangled while the ↵Fangrui Song2019-11-082-4/+24
| | | | | | | | | | | | definition is not When missing an extern "C" declaration, an undefined reference may be mangled while the definition is not. Suggest the missing extern "C" and the base name. Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D69592
* Keep symbols passed by -init and -finiRui Ueyama2019-11-081-0/+6
| | | | | | | | | | Previously, symbols passed by -init and -fini look as if they are not referenced by anyone, and the LTO might eliminate them. This patch fixes the issue. Fixes a bug reported in https://bugs.llvm.org/show_bug.cgi?id=43927 Differential Revision: https://reviews.llvm.org/D69985
* ELF: Discard .ARM.exidx sections for empty functions instead of misordering ↵Peter Collingbourne2019-11-041-5/+3
| | | | | | | | | | | | | | | them. The logic added in r372781 caused ARMExidxSyntheticSection::addSection() to return false for exidx sections without a link order dep that passed isValidExidxSectionDep(). This included exidx sections for empty functions. As a result, such exidx sections would end up treated like ordinary sections and would end up being laid out before the ARMExidxSyntheticSection, most likely in the wrong order relative to the exidx entries in the ARMExidxSyntheticSection, breaking the orderedness invariant relied upon by unwinders. Fix this by simply discarding such sections. Differential Revision: https://reviews.llvm.org/D69744
* comment typo fix to cycle botsNico Weber2019-10-311-1/+1
|
* comment typo fix to cycle botsNico Weber2019-10-301-2/+2
|
* [LLD][ELF] Support --[no-]mmap-output-file with F_no_mmapNick Terrell2019-10-294-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add a flag `F_no_mmap` to `FileOutputBuffer` to support `--[no-]mmap-output-file` in ELF LLD. LLD currently explicitly ignores this flag for compatibility with GNU ld and gold. We need this flag to speed up link time for large binaries in certain scenarios. When we link some of our larger binaries we find that LLD takes 50+ GB of memory, which causes memory pressure. The memory pressure causes the VM to flush dirty pages of the output file to disk. This is normally okay, since we should be flushing cold pages. However, when using BtrFS with compression we need to write 128KB at a time when we flush a page. If any page in that 128KB block is written again, then it must be flushed a second time, and so on. Since LLD doesn't write sequentially this causes write amplification. The same 128KB block will end up being flushed multiple times, causing the linker to many times more IO than necessary. We've observed 3-5x faster builds with -no-mmap-output-file when we hit this scenario. The bad scenario only applies to compressed filesystems, which group together multiple pages into a single compressed block. I've tested BtrFS, but the problem will be present for any compressed filesystem on Linux, since it is caused by the VM. Silently ignoring --no-mmap-output-file caused a silent regression when we switched from gold to lld. We pass --no-mmap-output-file to fix this edge case, but since lld silently ignored the flag we didn't realize it wasn't being respected. Benchmark building a 9 GB binary that exposes this edge case. I linked 3 times with --mmap-output-file and 3 times with --no-mmap-output-file and took the average. The machine has 24 cores @ 2.4 GHz, 112 GB of RAM, BtrFS mounted with -compress-force=zstd, and an 80% full disk. | Mode | Time | |---------|-------| | mmap | 894 s | | no mmap | 126 s | When compression is disabled, BtrFS performs just as well with and without mmap on this benchmark. I was unable to reproduce the regression with any binaries in lld-speed-test. Reviewed By: ruiu, MaskRay Differential Revision: https://reviews.llvm.org/D69294
* [ELF] Delete redundant comment after D56554. NFCFangrui Song2019-10-291-1/+0
|
* [lld] [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACKMichał Górny2019-10-293-8/+30
| | | | | | | | | Add a new '-z nognustack' option that suppresses emitting PT_GNU_STACK segment. This segment is not supported at all on NetBSD (stack is always non-executable), and the option is meant to be used to disable emitting it. Differential Revision: https://reviews.llvm.org/D56554
* Fix a few typos in lld/ELF to cycle botsNico Weber2019-10-2819-43/+43
|
* Crt files are special cased by name when dealing with ctor and dtorSterling Augustine2019-10-251-10/+16
| | | | | | | | | | | | | | sections, but the current code misses certain variants. In particular, those named when clang takes the code path in clang/lib/Driver/ToolChain.cpp:416, where crtfiles are named: clang_rt.<component>-<arch>-<env>.<suffix> Previously, the code only handled: clang_rt.<component>.<suffix> <component>.<suffix> This revision fixes that.
* [ELF] -r: fix crash when processing a SHT_REL[A] that relocates a SHF_MERGE ↵Fangrui Song2019-10-241-10/+10
| | | | | | | | | | | | | | | | | | | | after D67504/r372734 Fix PR43767 In -r mode, when processing a SHT_REL[A] that relocates a SHF_MERGE, sec->getRelocatedSection() is a MergeInputSection and its parent is an OutputSection but is asserted to be a SyntheticSection (MergeSyntheticSection) in LinkerScript.cpp:addInputSec(). ## The code path is not exercised in non -r mode because the relocated section changed from MergeInputSection to InputSection. Reorder the code to make the non -r logic apply to -r as well, thus fix the crash. Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D69364
* [LLD] Move duplicated dwarf parsing code to the Common library. NFC.Martin Storsjo2019-10-212-83/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D69197 llvm-svn: 375390
* [lld] Check for branch range overflows.Sid Manning2019-10-151-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D68875 llvm-svn: 374891
* [LLD][ELF] Fix stale comments about doing ICFRussell Gallop2019-10-101-2/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D68396 llvm-svn: 374362
* Make nullptr check more robustRui Ueyama2019-10-101-6/+4
| | | | | | | | | | | | The only condition that isecLoc becomes null is Out::bufferStart == nullptr, isec->getParent()->offset == 0, and isec->outSecOff == 0. We can check the first condition only once. llvm-svn: 374332
* [lld] getErrPlace(): don't perform arithmetics on maybe-null pointerRoman Lebedev2019-10-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | isecLoc there can be null, but at the same time isec->getSize() may be non-null. It is UB to offset a nullptr.The most straight-forward fix here appears to perform casts+normal integral arithmetics. FAIL: lld :: ELF/invalid/invalid-relocation-aarch64.test (1158 of 2217) ******************** TEST 'lld :: ELF/invalid/invalid-relocation-aarch64.test' FAILED ******************** Script: -- : 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o : 'RUN: at line 3'; not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-aarch64.test.tmp.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test -- Exit Code: 1 Command Output (stderr): -- /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-aarch64.test:4:10: error: CHECK: expected string not found in input # CHECK: error: unknown relocation (1024) against symbol foo ^ <stdin>:1:1: note: scanning from here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ <stdin>:1:118: note: possible intended match here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ -- ******************** Testing: 0.. 10.. 20.. 30.. 40.. 50. FAIL: lld :: ELF/invalid/invalid-relocation-x64.test (1270 of 2217) ******************** TEST 'lld :: ELF/invalid/invalid-relocation-x64.test' FAILED ******************** Script: -- : 'RUN: at line 2'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/yaml2obj /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o : 'RUN: at line 3'; echo ".global foo; foo:" > /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s : 'RUN: at line 4'; /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/llvm-mc /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.s -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -filetype=obj -triple x86_64-pc-linux : 'RUN: at line 5'; not /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/ld.lld /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp1.o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/lld/test/ELF/invalid/Output/invalid-relocation-x64.test.tmp2.o -o /dev/null 2>&1 | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test -- Exit Code: 1 Command Output (stderr): -- /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/test/ELF/invalid/invalid-relocation-x64.test:6:10: error: CHECK: expected string not found in input # CHECK: error: unknown relocation (152) against symbol foo ^ <stdin>:1:1: note: scanning from here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ <stdin>:1:118: note: possible intended match here /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/lld/ELF/Target.cpp:100:41: runtime error: applying non-zero offset 24 to null pointer ^ -- ******************** Testing: 0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Testing Time: 20.73s ******************** Failing Tests (2): lld :: ELF/invalid/invalid-relocation-aarch64.test lld :: ELF/invalid/invalid-relocation-x64.test llvm-svn: 374329
OpenPOWER on IntegriCloud