summaryrefslogtreecommitdiffstats
path: root/lld/ELF/Config.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Factor out code to parse -pack-dyn-relocs. NFC.Rui Ueyama2018-07-091-2/+2
| | | | llvm-svn: 336599
* lld: add experimental support for SHT_RELR sections.Rui Ueyama2018-07-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Rahul Chaudhry! This change adds experimental support for SHT_RELR sections, proposed here: https://groups.google.com/forum/#!topic/generic-abi/bX460iggiKg Pass '--pack-dyn-relocs=relr' to enable generation of SHT_RELR section and DT_RELR, DT_RELRSZ, and DT_RELRENT dynamic tags. Definitions for the new ELF section type and dynamic array tags, as well as the encoding used in the new section are all under discussion and are subject to change. Use with caution! Pass '--use-android-relr-tags' with '--pack-dyn-relocs=relr' to use SHT_ANDROID_RELR section type instead of SHT_RELR, as well as DT_ANDROID_RELR* dynamic tags instead of DT_RELR*. The generated section contents are identical. '--pack-dyn-relocs=android+relr --use-android-relr-tags' enables both '--pack-dyn-relocs=android' and '--pack-dyn-relocs=relr': lld will encode the relative relocations in a SHT_ANDROID_RELR section, and pack the rest of the dynamic relocations in a SHT_ANDROID_REL(A) section. Differential Revision: https://reviews.llvm.org/D48247 llvm-svn: 336594
* [ELF] Support -z initfirstFangrui Song2018-06-201-0/+1
| | | | | | | | | | | | | | | | Summary: glibc uses this option to link libpthread.so glibc/nptl/Makefile: LDFLAGS-pthread.so = -Wl,--enable-new-dtags,-z,nodelete,-z,initfirst Reviewers: ruiu, echristo, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D48329 llvm-svn: 335090
* [ELF][MIPS] Multi-GOT implementationSimon Atanasyan2018-06-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Almost all entries inside MIPS GOT are referenced by signed 16-bit index. Zero entry lies approximately in the middle of the GOT. So the total number of GOT entries cannot exceed ~16384 for 32-bit architecture and ~8192 for 64-bit architecture. This limitation makes impossible to link rather large application like for example LLVM+Clang. There are two workaround for this problem. The first one is using the -mxgot compiler's flag. It enables using a 32-bit index to access GOT entries. But each access requires two assembly instructions two load GOT entry index to a register. Another workaround is multi-GOT. This patch implements it. Here is a brief description of multi-GOT for detailed one see the following link https://dmz-portal.mips.com/wiki/MIPS_Multi_GOT. If the sum of local, global and tls entries is less than 64K only single got is enough. Otherwise, multi-got is created. Series of primary and multiple secondary GOTs have the following layout: ``` - Primary GOT Header Local entries Global entries Relocation only entries TLS entries - Secondary GOT Local entries Global entries TLS entries ... ``` All GOT entries required by relocations from a single input file entirely belong to either primary or one of secondary GOTs. To reference GOT entries each GOT has its own _gp value points to the "middle" of the GOT. In the code this value loaded to the register which is used for GOT access. MIPS 32 function's prologue: ``` lui v0,0x0 0: R_MIPS_HI16 _gp_disp addiu v0,v0,0 4: R_MIPS_LO16 _gp_disp ``` MIPS 64 function's prologue: ``` lui at,0x0 14: R_MIPS_GPREL16 main ``` Dynamic linker does not know anything about secondary GOTs and cannot use a regular MIPS mechanism for GOT entries initialization. So we have to use an approach accepted by other architectures and create dynamic relocations R_MIPS_REL32 to initialize global entries (and local in case of PIC code) in secondary GOTs. But ironically MIPS dynamic linker requires GOT entries and correspondingly ordered dynamic symbol table entries to deal with dynamic relocations. To handle this problem relocation-only section in the primary GOT contains entries for all symbols referenced in global parts of secondary GOTs. Although the sum of local and normal global entries of the primary got should be less than 64K, the size of the primary got (including relocation-only entries can be greater than 64K, because parts of the primary got that overflow the 64K limit are used only by the dynamic linker at dynamic link-time and not by 16-bit gp-relative addressing at run-time. The patch affects common LLD code in the following places: - Added new hidden -mips-got-size flag. This flag required to set low maximum size of a single GOT to be able to test the implementation using small test cases. - Added InputFile argument to the getRelocTargetVA function. The same symbol referenced by GOT relocation from different input file might be allocated in different GOT. So result of relocation depends on the file. - Added new ctor to the DynamicReloc class. This constructor records settings of dynamic relocation which used to adjust address of 64kb page lies inside a specific output section. With the patch LLD is able to link all LLVM+Clang+LLD applications and libraries for MIPS 32/64 targets. Differential revision: https://reviews.llvm.org/D31528 llvm-svn: 334390
* Add support for ThinLTO plugin option thinlto-object-suffix-replaceRumeet Dhindsa2018-05-161-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D46608 llvm-svn: 332527
* New option -z keep-text-section-prefix to keep text sections with prefixes ↵Sriraman Tallam2018-05-081-0/+1
| | | | | | | | | | separate. Separate output sections for selected text section prefixes to enable TLB optimizations and for readablilty. Differential Revision: https://reviews.llvm.org/D45841 llvm-svn: 331823
* Add support for LTO plugin option obj-pathRumeet Dhindsa2018-05-081-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D46598 llvm-svn: 331817
* Rename Config::ThinLTOIndexOnlyObjectFiles -> Config::ThinLTOIndexOnlyArg.Rui Ueyama2018-05-071-1/+1
| | | | llvm-svn: 331699
* Add support for thinlto option ( thinlto-emit-imports-files) to emit import ↵Rumeet Dhindsa2018-05-071-0/+1
| | | | | | | | files for thinlink. Differential Revision: https://reviews.llvm.org/D46400 llvm-svn: 331696
* Parse --thinlto-prefix-replace early so that we don't need to parse it ↵Rui Ueyama2018-05-071-1/+1
| | | | | | later. NFC. llvm-svn: 331657
* Added support for ThinLTO plugin options : thinlto-index-only and ↵Rumeet Dhindsa2018-05-021-0/+3
| | | | | | | | thinlto-prefix-replace Differential Revision: https://reviews.llvm.org/D46034 llvm-svn: 331405
* Add -z {combreloc,copyreloc,noexecstack,lazy,relro,text}.Rui Ueyama2018-04-201-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D45902 llvm-svn: 330482
* [ELF] Add profile guided section layoutMichael J. Spencer2018-04-171-0/+4
| | | | | | | | | | | | | | | | | This adds profile guided layout using the Call-Chain Clustering (C³) heuristic from https://research.fb.com/wp-content/uploads/2017/01/cgo2017-hfsort-final1.pdf . RFC: [llvm-dev] [RFC] Profile guided section layout http://lists.llvm.org/pipermail/llvm-dev/2017-June/114178.html Pass `--call-graph-ordering-file <file>` to read a call graph profile where each line has the format: <from symbol> <to symbol> <call count> Differential Revision: https://reviews.llvm.org/D36351 llvm-svn: 330234
* Add --warn-backrefs to maintain compatibility with other linkersRui Ueyama2018-04-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm proposing a new command line flag, --warn-backrefs in this patch. The flag and the feature proposed below don't exist in GNU linkers nor the current lld. --warn-backrefs is an option to detect reverse or cyclic dependencies between static archives, and it can be used to keep your program compatible with GNU linkers after you switch to lld. I'll explain the feature and why you may find it useful below. lld's symbol resolution semantics is more relaxed than traditional Unix linkers. Therefore, ld.lld foo.a bar.o succeeds even if bar.o contains an undefined symbol that have to be resolved by some object file in foo.a. Traditional Unix linkers don't allow this kind of backward reference, as they visit each file only once from left to right in the command line while resolving all undefined symbol at the moment of visiting. In the above case, since there's no undefined symbol when a linker visits foo.a, no files are pulled out from foo.a, and because the linker forgets about foo.a after visiting, it can't resolve undefined symbols that could have been resolved otherwise. That lld accepts more relaxed form means (besides it makes more sense) that you can accidentally write a command line or a build file that works only with lld, even if you have a plan to distribute it to wider users who may be using GNU linkers. With --check-library-dependency, you can detect a library order that doesn't work with other Unix linkers. The option is also useful to detect cyclic dependencies between static archives. Again, lld accepts ld.lld foo.a bar.a even if foo.a and bar.a depend on each other. With --warn-backrefs it is handled as an error. Here is how the option works. We assign a group ID to each file. A file with a smaller group ID can pull out object files from an archive file with an equal or greater group ID. Otherwise, it is a reverse dependency and an error. A file outside --{start,end}-group gets a fresh ID when instantiated. All files within the same --{start,end}-group get the same group ID. E.g. ld.lld A B --start-group C D --end-group E A and B form group 0, C, D and their member object files form group 1, and E forms group 2. I think that you can see how this group assignment rule simulates the traditional linker's semantics. Differential Revision: https://reviews.llvm.org/D45195 llvm-svn: 329636
* Added support for LTO options: sample_profile, new_pass_manager and ↵Rumeet Dhindsa2018-04-091-0/+3
| | | | | | | | debug_pass_manager Differential Revision: https://reviews.llvm.org/D45275 llvm-svn: 329598
* Implement --cref.Rui Ueyama2018-03-141-0/+1
| | | | | | | | | | | | | | This is an option to print out a table of symbols and filenames. The output format of this option is the same as GNU, so that it can be processed by the same scripts as before after migrating from GNU to lld. This option is mildly useful; we can live without it. But it is pretty convenient sometimes, and it can be implemented in 50 lines of code, so I think lld should support this option. Differential Revision: https://reviews.llvm.org/D44336 llvm-svn: 327565
* [mips][lld] Spectre variant two mitigation for MIPSR2Simon Dardis2018-02-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch provides migitation for CVE-2017-5715, Spectre variant two, which affects the P5600 and P6600. It implements the LLD part of -z hazardplt. Like the Clang part of this patch, I have opted for that specific option name in case alternative migitation methods are required in the future. The mitigation strategy suggested by MIPS for these processors is to use hazard barrier instructions. 'jalr.hb' and 'jr.hb' are hazard barrier variants of the 'jalr' and 'jr' instructions respectively. These instructions impede the execution of instruction stream until architecturally defined hazards (changes to the instruction stream, privileged registers which may affect execution) are cleared. These instructions in MIPS' designs are not speculated past. These instructions are defined by the MIPS32R2 ISA, so this mitigation method is not compatible with processors which implement an earlier revision of the MIPS ISA. For LLD, this changes PLT stubs to use 'jalr.hb' and 'jr.hb'. Reviewers: atanasyan, ruiu Differential Revision: https://reviews.llvm.org/D43488 llvm-svn: 325647
* Consistent (non) use of empty lines in include blocksSam Clegg2018-02-201-1/+0
| | | | | | | | | The profailing style in lld seem to be to not include such empty lines. Clang-tidy/clang-format seem to handle this just fine. Differential Revision: https://reviews.llvm.org/D43528 llvm-svn: 325629
* Remove "--full-shutdown" and instead use an environment variable LLD_IN_TEST.Rui Ueyama2018-02-161-1/+0
| | | | | | | | | | | | | | | | | We are running lld tests with "--full-shutdown" option because we don't want to call _exit() in lld if it is running tests. Regular shutdown is needed for leak sanitizer. This patch changes the way how we tell lld that it is running tests. Now "--full-shutdown" is removed, and LLD_IN_TEST environment variable is used instead. This patch enables full shutdown on all ports, e.g. ELF, COFF and wasm. Previously, we enabled it only for ELF. Differential Revision: https://reviews.llvm.org/D43410 llvm-svn: 325413
* [ELF] Add warnings for various symbols that cannot be orderedJames Henderson2018-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | There are a number of different situations when symbols are requested to be ordered in the --symbol-ordering-file that cannot be ordered for some reason. To assist with identifying these symbols, and either tidying up the order file, or the inputs, a number of warnings have been added. As some users may find these warnings unhelpful, due to how they use the symbol ordering file, a switch has also been added to disable these warnings. The cases where we now warn are: * Entries in the order file that don't correspond to any symbol in the input * Undefined symbols * Absolute symbols * Symbols imported from shared objects * Symbols that are discarded, due to e.g. --gc-sections or /DISCARD/ linker script sections * Multiple of the same entry in the order file Reviewed by: rafael, ruiu Differential Revision: https://reviews.llvm.org/D42475 llvm-svn: 325125
* Remove Config->Verbose because we have errorHandler().Verbose.Rui Ueyama2018-02-081-1/+0
| | | | llvm-svn: 324684
* Store just argv[0] in Config.Rafael Espindola2018-02-061-1/+1
| | | | | | | Having the full argv there seems in conflict with the desire to parse all command line options in the Driver. llvm-svn: 324418
* Replace ApplyDynamicRelocs with WriteAddends.Rafael Espindola2018-02-051-1/+1
| | | | | | | The difference is that WriteAddends also takes IsRela into consideration. llvm-svn: 324271
* [ELF] Implement --[no-]apply-dynamic-relocs option.Peter Smith2018-02-051-0/+1
| | | | | | | | | | | | | | | | When resolving dynamic RELA relocations the addend is taken from the relocation and not the place being relocated. Accordingly lld does not write the addend field to the place like it would for a REL relocation. Unfortunately there is some system software, in particlar dynamic loaders such as Bionic's linker64 that use the value of the place prior to relocation to find the offset that they have been loaded at. Both gold and bfd control this behavior with the --[no-]apply-dynamic-relocs option. This change implements the option and defaults it to true for compatibility with gold and bfd. Differential Revision: https://reviews.llvm.org/D42797 llvm-svn: 324221
* Add -{no,}-check-sections flags to enable/disable section overlcheckingRui Ueyama2018-02-021-0/+1
| | | | | | | | GNU linkers have this option. Differential Revision: https://reviews.llvm.org/D42858 llvm-svn: 324150
* Add --no-gnu-unique and --no-undefined-version for completeness.Rui Ueyama2018-02-021-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D42865 llvm-svn: 324145
* [ELF] Add --print-icf-sections flagJames Henderson2018-02-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Currently ICF information is output through stderr if the "--verbose" flag is used. This differs to Gold for example, which uses an explicit flag to output this to stdout. This commit adds the "--print-icf-sections" and "--no-print-icf-sections" flags and changes the output message format for clarity and consistency with "--print-gc-sections". These messages are still output to stderr if using the verbose flag. However to avoid intermingled message output to console, this will not occur when the "--print-icf-sections" flag is used. Existing tests have been modified to expect the new message format from stderr. Patch by Owen Reynolds. Differential Revision: https://reviews.llvm.org/D42375 Reviewers: ruiu, rafael Reviewed by: llvm-svn: 323976
* [ELF] Make overlapping output sections an errorAlexander Richardson2018-01-311-0/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: While trying to make a linker script behave the same way with lld as it did with bfd, I discovered that lld currently doesn't diagnose overlapping output sections. I was getting very strange runtime failures which I tracked down to overlapping sections in the resulting binary. When linking with ld.bfd overlapping output sections are an error unless --noinhibit-exec is passed and I believe lld should behave the same way here to avoid surprising crashes at runtime. The patch also uncovered an errors in the tests: arm-thumb-interwork-thunk was creating a binary where .got.plt was placed at an address overlapping with .got. Reviewers: ruiu, grimar, rafael Reviewed By: ruiu Differential Revision: https://reviews.llvm.org/D41046 llvm-svn: 323856
* Introduce the "retpoline" x86 mitigation technique for variant #2 of the ↵Chandler Carruth2018-01-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.. Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain. The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers. However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address. On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address. This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886 We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction. There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection. The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness. For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller. When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typical workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel. When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline. We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors. This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design. Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D41723 llvm-svn: 323155
* Rename --icf-data and add a corresponding flag for functions.Rafael Espindola2018-01-101-1/+2
| | | | | | | | | | When we have --icf=safe we should be able to define --icf=all as a shorthand for --icf=safe --ignore-function-address-equality. For now --ignore-function-address-equality is used only to control access to non preemptable symbols in shared libraries. llvm-svn: 322152
* [ELF] Remove Duplicate .ARM.exidx sectionsPeter Smith2017-12-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The ARM.exidx section contains a table of 8-byte entries with the first word of each entry an offset to the function it describes and the second word instructions for unwinding if an exception is thrown from that function. The SHF_LINK_ORDER processing will order the table in ascending order of the functions described by the exception table entries. As the address range of an exception table entry is terminated by the next table entry, it is possible to merge consecutive table entries that have identical unwind instructions. For this implementation we define a table entry to be identical if: - Both entries are the special EXIDX_CANTUNWIND. - Both entries have the same inline unwind instructions. We do not attempt to establish if table entries that are references to .ARM.extab sections are identical. This implementation works at a granularity of a single .ARM.exidx InputSection. If all entries in the InputSection are identical to the previous table entry we can remove the InputSection. A more sophisticated but more complex implementation would rewrite InputSection contents so that duplicates within a .ARM.exidx InputSection can be merged. Differential Revision: https://reviews.llvm.org/D40967 llvm-svn: 320803
* Add an option for ICFing data.Rafael Espindola2017-12-121-0/+1
| | | | | | | | | | An internal linker has support for merging identical data and in some cases it can be a significant win. This is behind an off by default flag so it has to be requested explicitly. llvm-svn: 320448
* [ELF] Implement scanner for Cortex-A53 Erratum 843419Peter Smith2017-12-051-0/+1
| | | | | | | | | | | | | | Add a new file AArch64ErrataFix.cpp that implements the logic to scan for the Cortex-A53 Erratum 843419. This involves finding all the executable code, disassembling the instructions that might trigger the erratum and reporting a message if the sequence is detected. At this stage we do not attempt to fix the erratum, this functionality will be added in a later patch. See D36749 for proposal. Differential Revision: https://reviews.llvm.org/D36742 llvm-svn: 319780
* [ELF] Read ARM BuildAttributes section to determine supported features.Peter Smith2017-11-281-0/+3
| | | | | | | | | | | | | | | | | | | lld assumes some ARM features that are not available in all Arm processors. In particular: - The blx instruction present for interworking. - The movt/movw instructions are used in Thunks. - The J1=1 J2=1 encoding of branch immediates to improve Thumb wide branch range are assumed to be present. This patch reads the ARM Attributes section to check for the architecture the object file was compiled with. If none of the objects have an architecture that supports either of these features a warning will be given. This is most likely to affect armv6 as used in the first Raspberry Pi. Differential Revision: https://reviews.llvm.org/D36823 llvm-svn: 319169
* Merge SymbolBody and Symbol into one class, SymbolBody.Rui Ueyama2017-10-311-1/+0
| | | | | | | | | | | | | | | | | | | SymbolBody and Symbol were separated classes due to a historical reason. Symbol used to be a pointer to a SymbolBody, and the relationship between Symbol and SymbolBody was n:1. r2681780 changed that. Since that patch, SymbolBody and Symbol are allocated next to each other to improve memory locality, and they have 1:1 relationship now. So, the separation of Symbol and SymbolBody no longer makes sense. This patch merges them into one class. In order to avoid updating too many places, I chose SymbolBody as a unified name. I'll rename it Symbol in a follow-up patch. Differential Revision: https://reviews.llvm.org/D39406 llvm-svn: 317006
* ELF: Add support for emitting dynamic relocations in the Android relocation ↵Peter Collingbourne2017-10-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | packing format. The Android relocation packing format is a more compact format for dynamic relocations in executables and DSOs that is based on delta encoding and SLEBs. An overview of the format can be found in the Android source code: https://android.googlesource.com/platform/bionic/+/refs/heads/master/tools/relocation_packer/src/delta_encoder.h This patch implements relocation packing using that format. This implementation uses a more intelligent algorithm for compressing relative relocations than Android's own relocation packer. As a result it can generally create smaller relocation sections than that packer. If I link Chromium for Android targeting ARM32 I get a .rel.dyn of size 174693 bytes, as compared to 371832 bytes with gold and the Android packer. Differential Revision: https://reviews.llvm.org/D39152 llvm-svn: 316775
* [lld] unified COFF and ELF error handling on new Common/ErrorHandlerBob Haarman2017-10-251-3/+0
| | | | | | | | | | | | | | | | | | | Summary: The COFF linker and the ELF linker have long had similar but separate Error.h and Error.cpp files to implement error handling. This change introduces new error handling code in Common/ErrorHandler.h, changes the COFF and ELF linkers to use it, and removes the old, separate implementations. Reviewers: ruiu Reviewed By: ruiu Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits Differential Revision: https://reviews.llvm.org/D39259 llvm-svn: 316624
* [ELF] - Implement --orphan-handling option.George Rimar2017-10-251-0/+4
| | | | | | | | | | | | | | | | | | It is PR34946. Spec (http://man7.org/linux/man-pages/man1/ld.1.html) tells about --orphan-handling=MODE, option where MODE can be one of four: "place", "discard", "warn", "error". Currently we already report orphans when -verbose given, what becomes excessive with option implemented. Patch stops reporting orphans when -versbose is given, and support "place", "warn" and "error" modes. It is not yet clear that "discard" mode is useful so it is not supported. Differential revision: https://reviews.llvm.org/D39000 llvm-svn: 316583
* LLD/ELF: Allow targets to set e_flagsKonstantin Zhuravlyov2017-10-241-5/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D39139 llvm-svn: 316460
* Remove Config::FirstElf.Rui Ueyama2017-10-151-1/+0
| | | | llvm-svn: 315881
* [lld] Move Threads to CommonBob Haarman2017-10-131-1/+0
| | | | | | | | | | | | | | | | Summary: This will allow using the functionality from other linkers. It is also a prerequisite for sharing the error logging code. Reviewers: ruiu Reviewed By: ruiu Subscribers: emaste, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D38822 llvm-svn: 315725
* [ELF] Set Dot initially to --image-base value when using linker scriptsJames Henderson2017-10-101-1/+1
| | | | | | | | | | | | | | | | | | | | | When parsing linker scripts, LLD previously started with a '.' value of 0, regardless of the internal default image base for the target, and regardless of switches such as --image-base. It seems reasonable to use a different image base value when using linker scripts and --image-base is specified, since otherwise the switch has no effect. This change does this, as well as removing unnecessary initialisation of Dot where it is not used. The default image base should not be used when processing linker scripts, because this will change the behaviour for existing linker script users, and potentially result in invalid output being produced, as a subsequent assignment to Dot could move the location counter backwards. Instead, we maintain the existing behaviour of starting from 0 if --image-base is not specified. Reviewers: ruiu Differential Revision: https://reviews.llvm.org/D38360 llvm-svn: 315293
* [ELF] - Do --hash-style=both by default.George Rimar2017-10-061-2/+2
| | | | | | | | | | | | | | Its PR34712, GNU linkers recently changed default values to "both" of "sysv". Patch do the same for all targets except MIPS, where .gnu.hash section is not yet supported. Code suggested by Rui Ueyama. Differential revision: https://reviews.llvm.org/D38407 llvm-svn: 315051
* Remove dead code.Rafael Espindola2017-10-051-7/+0
| | | | llvm-svn: 314966
* [MIPS] Fix PLT entries generation in case of linking regular and microMIPS codeSimon Atanasyan2017-10-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently LLD calls the `isMicroMips` routine to determine type of PLT entries needs to be generated: regular or microMIPS. This routine checks ELF header flags in the `FirstObj` to retrieve type of linked object files. So if the first file does not contain microMIPS code, LLD will generate PLT entries with regular (non-microMIPS) code only. Ideally, if a PLT entry is referenced by microMIPS code only this entry should contain microMIPS code, if a PLT entry is referenced by regular code this entry should contain regular code. In a "mixed" case the PLT entry can be either microMIPS or regular, but each "cross-mode-call" has additional cost. It's rather difficult to implement this ideal solution. But we can assume that if there is an input object file with microMIPS code, the most part of the code is microMIPS too. So we need to deduce type of PLT entries based on finally calculated ELF header flags and do not check only the first input object file. This change implements this. - The `getMipsEFlags` renamed to the `calcMipsEFlags`. The function called from the `LinkerDriver::link`. Result is stored in the Configuration::MipsEFlags field. - The `isMicroMips` and `isMipsR6` routines access the `MipsEFlags` field to get and check calculated ELF flags. - New types of PLT records created when necessary. Differential revision: https://reviews.llvm.org/D37747 llvm-svn: 314675
* Keep some relocations with undefined weak symbols.Rafael Espindola2017-09-151-0/+1
| | | | | | | | | | | | | | | | | | | This fixes pr34301. As the bug points out, we want to keep some relocations with undefined weak symbols. This means that we cannot always claim that these symbols are not preemptible as we do now. Unfortunately, we cannot also just always claim that they are preemptible. Doing so would, for example, cause us to try to create a plt entry when we don't even have a dynamic symbol table. What almost works is to say that weak undefined symbols are preemptible if and only if we have a dynamic symbol table. Almost because we don't want to fail the build trying to create a copy relocation to a weak undefined. llvm-svn: 313372
* Handle empty dynamic lists.Rafael Espindola2017-09-081-0/+1
| | | | llvm-svn: 312820
* If --dynamic-list is given, only those symbols are preemptible.Rafael Espindola2017-09-081-0/+1
| | | | | | | | | | | | | This allows combining --dynamic-list and version scripts too. The version script controls which symbols are visible, and --dynamic-list controls which of those are preemptible. Unlike previous versions, undefined symbols are still considered preemptible, which was the issue breaking the cfi tests. This fixes pr34053. llvm-svn: 312806
* Revert "Revert "Revert r311468: If --dynamic-list is given, only those ↵Rafael Espindola2017-09-081-1/+0
| | | | | | | | | | symbols are preemptible"" This reverts commit r312757. Evgenii Stepanov reports that it broke some tests. llvm-svn: 312771
* Revert "Revert r311468: If --dynamic-list is given, only those symbols are ↵Rafael Espindola2017-09-071-0/+1
| | | | | | | | | | | | | | preemptible" If --dynamic-list is given, only those symbols are preemptible. This allows combining --dynamic-list and version scripts too. The version script controls which symbols are visible, and --dynamic-list controls which of those are preemptible. This fixes pr34053. llvm-svn: 312757
OpenPOWER on IntegriCloud