summaryrefslogtreecommitdiffstats
path: root/lld/ELF/SyntheticSections.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF] Fix link failure with Android compressed relocation support.Eli Friedman2018-10-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Android uses a compressed relocation format, which means the size of the relocation section isn't predictable based on the number of relocations, and can vary if the layout changes in any way. To deal with this, the linker normally runs multiple passes until the layout converges. The layout should converge if the size of the compressed relocation section increases monotonically: if the size of an encoded offset increases by one byte, the larget value which can be encoded is multiplied by 128, so the representable offsets grow much faster than the size of the section itself. The problem here is that there is no code to ensure the size of the section doesn't decrease. If the size of the relocation section decreases, the relative offsets can increase due to alignment restrictions, so that can force the size of the relocation section to increase again. The end result is an infinite loop; the loop gets cut off after 10 iterations with the message "thunk creation not converged". To avoid this issue, this patch adds padding to the end of the relocation section if its size would decrease. The extra padding is harmless because of the way the format is defined: decoding stops after it reaches the number of relocations specified in the section's header. Differential Revision: https://reviews.llvm.org/D53003 llvm-svn: 344300
* [ELF] - Set sh_info and sh_link for .rela.plt sections.George Rimar2018-10-111-3/+6
| | | | | | | | | | | | | | | | | | | | This is https://bugs.llvm.org/show_bug.cgi?id=37538, Currently, LLD may set both sh_link and sh_info for .rela.plt section to zero when we have only .rela.iplt section part used. ELF spec (https://docs.oracle.com/cd/E19683-01/816-1386/chapter6-94076/index.html) says that for SHT_REL and SHT_RELA, sh_link references the associated symbol table and sh_info the "section to which the relocation applies." When we set the sh_link field, for the regular case we use the .dynsym index. For .rela.iplt sections, it is unclear what is the associated symbol table, because R_*_RELATIVE relocations do not use symbol names and we might have no .dynsym section at all so this patch uses .symtab section index. Differential revision: https://reviews.llvm.org/D52830 llvm-svn: 344226
* Avoid unnecessary buffer allocation and memcpy for compressed sections.Rui Ueyama2018-10-081-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we uncompress all compressed sections before doing anything. That works, and that is conceptually simple, but that could results in a waste of CPU time and memory if uncompressed sections are then discarded or just copied to the output buffer. In particular, if .debug_gnu_pub{names,types} are compressed and if no -gdb-index option is given, we wasted CPU and memory because we uncompress them into newly allocated bufers and then memcpy the buffers to the output buffer. That temporary buffer was redundant. This patch changes how to uncompress sections. Now, compressed sections are uncompressed lazily. To do that, `Data` member of `InputSectionBase` is now hidden from outside, and `data()` accessor automatically expands an compressed buffer if necessary. If no one calls `data()`, then `writeTo()` directly uncompresses compressed data into the output buffer. That eliminates the redundant memory allocation and redundant memcpy. This patch significantly reduces memory consumption (20 GiB max RSS to 15 Gib) for an executable whose .debug_gnu_pub{names,types} are in total 5 GiB in an uncompressed form. Differential Revision: https://reviews.llvm.org/D52917 llvm-svn: 343979
* [ELF] - Simplify. NFCI.George Rimar2018-10-041-4/+2
| | | | | | Assign the `Link` to parent directly. llvm-svn: 343762
* [ELF] llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-8/+6
| | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: ruiu, espindola Subscribers: emaste, arichardson, mgrang, llvm-commits Differential Revision: https://reviews.llvm.org/D52569 llvm-svn: 343146
* De-template VersionDefinitionSection. NFC.Rui Ueyama2018-09-251-39/+33
| | | | | | | | When we write a struct to a mmap'ed buffer, we usually use write16/32/64, but we didn't for VersionDefinitionSection, so we needed to template that class. llvm-svn: 343024
* Reset input section pointers to null on each linker invocation.Rui Ueyama2018-09-251-116/+89
| | | | | | | | | | Previously, if you invoke lld's `main` more than once in the same process, the second invocation could fail or produce a wrong result due to a stale pointer values of the previous run. Differential Revision: https://reviews.llvm.org/D52506 llvm-svn: 343009
* Parallelize .gdb_index string table writes.Rui Ueyama2018-09-251-1/+2
| | | | | | When we are creating a large .gdb_index, this change makes a difference. llvm-svn: 342978
* [ELF] Use llvm::toLower instead of libc call tolowerFangrui Song2018-09-151-1/+2
| | | | | | | | | | | | | | | | | | | tolower() has some overhead because current locale is considered (though in lld the default "C" locale is used which does not matter too much). llvm::toLower is more efficient as it compiles to a compare and a conditional jump, as opposed to a libc call if tolower is used. Disregarding locale also matches gdb's behavior (gdb/minsyms.h): #define SYMBOL_HASH_NEXT(hash, c) \ ((hash) * 67 + TOLOWER ((unsigned char) (c)) - 113) where TOLOWER (include/safe-ctype.h) is a macro that uses a lookup table under the hood which is similar to llvm::toLower. Reviewers: ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D52128 llvm-svn: 342342
* Revert r342297: Discard uncompressed buffer after creating .gdb_index contents.Rui Ueyama2018-09-141-10/+7
| | | | | | Looks like it broke some local builds that use -gdb-index. llvm-svn: 342298
* Discard uncompressed buffer after creating .gdb_index contents.Rui Ueyama2018-09-141-7/+10
| | | | | | | | | | | | | | Once we create .gdb_index contents, .zdebug_gnu_pub{names,types} are useless, so there's no need to keep their uncompressed data in memory. I observed that for a test case in which lld creates a 3GB .gdb_index section, the maximum resident set size reduced from 43GB to 29GB after this patch. Differential Revision: https://reviews.llvm.org/D52126 llvm-svn: 342297
* lld: add -z interpose supportEd Maste2018-09-141-0/+2
| | | | | | | | | | | -z interpose sets the DF_1_INTERPOSE flag, marking the object as an interposer. Via FreeBSD PR 230604, linking Valgrind with lld failed. Differential Revision: https://reviews.llvm.org/D52094 llvm-svn: 342239
* [LLF][ELF] - Support -z global.George Rimar2018-08-281-0/+2
| | | | | | | | -z global is a flag used on Android (see D49198). Differential revision: https://reviews.llvm.org/D49374 llvm-svn: 340802
* [LLD][ELF] - Fix warning.George Rimar2018-08-201-1/+2
| | | | | | | | | This fixes the following warning when compiling with gcc version 8.0.1 20180319 (experimental) (GCC): /home/umb/LLVM/llvm/tools/lld/ELF/SyntheticSections.cpp:1951:46: warning: enumeral and non-enumeral type in conditional expression [-Wextra] return OS->SectionIndex >= SHN_LORESERVE ? SHN_XINDEX : OS->SectionIndex; llvm-svn: 340164
* [ELF] mergeSections: remove non-alive MergeInputSectionFangrui Song2018-08-161-1/+3
| | | | | | | | | | | | | | Summary: This makes it conform to what the comment says. Otherwise when getErrPlace() is called afterwards, cast<InputSection>(D) will cause incompatible cast as MergeInputSection is not a subclass of InputSection. Reviewers: ruiu, grimar, espindola, pcc Reviewed By: grimar Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D50742 llvm-svn: 339904
* [ELF] - Get rid of SyntheticSection::postThunkContents(). NFCI.George Rimar2018-08-101-4/+4
| | | | | | | | | | | | It turns out that postThunkContents() is only used for sorting symbols in .symtab. Though we can instead move the logic to SymbolTableBaseSection::finalizeContents(), postpone calling it and then get rid of postThunkContents completely. Differential revision: https://reviews.llvm.org/D49547 llvm-svn: 339413
* Update for DWARF API changeReid Kleckner2018-08-011-2/+2
| | | | llvm-svn: 338642
* Simplify. NFC.Rui Ueyama2018-07-311-1/+1
| | | | llvm-svn: 338409
* [ELF] - Implement SHT_SYMTAB_SHNDX (.symtab_shndxr) section.George Rimar2018-07-301-17/+58
| | | | | | | | | | | | | | | | This is relative to https://bugs.llvm.org//show_bug.cgi?id=38119. SHT_SYMTAB section is able to keep symbols with output section indices up to 0xff00 (SHN_LORESERVE). But if we have indices that are greater than that (PR shows that it might happen), we need to use SHT_SYMTAB_SHNDX extended section. It was not supported by LLD. Description of the SHT_SYMTAB_SHNDX section is here: https://docs.oracle.com/cd/E19683-01/817-3677/chapter6-94076/index.html. Differential revision: https://reviews.llvm.org/D49541 llvm-svn: 338247
* [ELF][MIPS] Fix primary GOT sometimes overflowing by one or two wordsSimon Atanasyan2018-07-241-1/+7
| | | | | | | | | | | | | | | | If we fail to merge a secondary GOT with the primary GOT but so far only one merged GOT has been created (the primary one), the final element in MergedGots is the primary GOT. Thus we should not try to merge with this final element passing IsPrimary=false, since this will ignore the fact that the destination GOT does in fact need a header, and those extra two entries can be enough to allow the merge to incorrectly occur. Instead we should check for this case before attempting the second merge. Patch by James Clarke. Differential revision: https://reviews.llvm.org/D49422 llvm-svn: 337810
* [ELF] Fix handling of FDE negative relative PC addrAndrew Ng2018-07-231-1/+6
| | | | | | | | | | | | | | Signed values for the FDE PC addr were not correctly handled in readFdeAddr(). If the value is negative and the type of the value is smaller than 64 bits, the FDE PC addr overflow error would be incorrectly triggered. Fixed readFdeAddr() to properly handle signed values by sign extending where appropriate. Differential Revision: https://reviews.llvm.org/D49557 llvm-svn: 337683
* [ELF] Check eh_frame_hdr overflow with PC offsets instead of PC absolute ↵Fangrui Song2018-07-201-15/+21
| | | | | | | | | | | | addresses Reviewers: grimar, ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D49607 llvm-svn: 337610
* [ELF] - Eliminate dead code. NFC.George Rimar2018-07-191-2/+1
| | | | | | Code was dead because we call postThunkContents only for SHT_SYMTAB. llvm-svn: 337460
* [ELF] - Stop silently producing a broken .eh_frame_hdr.George Rimar2018-07-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, getFdePC() returns uint64_t. Its because the following encodings might use 8 bytes: DW_EH_PE_absptr and DW_EH_PE_udata8. But caller assigns returned value to uint32_t field: https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L508 Value is used for building .eh_frame_hdr section. We use DW_EH_PE_sdata4 encoding for building it at this moment: https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L2545 And that means that an overflow issue might happen if DW_EH_PE_absptr/DW_EH_PE_udata8 address encodings are present in .eh_frame. In that case, before this patch, we silently would truncate the address and produced broken .eh_frame_hdr section. It would be not hard to support real 64-bit values for DW_EH_PE_absptr/DW_EH_PE_udata8 encodings, but it is unclear if it is usefull and if we should do it. Since nobody faced/reported it, int this patch I only implement a check to stop producing broken output silently for now. llvm-svn: 337382
* [ELF] - Eliminate dead 'return' in EhFrameSection::finalizeContents(). NFC.George Rimar2018-07-171-3/+1
| | | | | | | | | EhFrameSection::finalizeContents() is called from a single place: https://github.com/llvm-mirror/lld/blob/master/ELF/Writer.cpp#L1559 So code was dead. llvm-svn: 337287
* [ELF] - Remove dead code from EhFrameSection::addCie. NFC.George Rimar2018-07-171-5/+1
| | | | | | | | Code was dead because caller of the addCie() already checks that ID is equal to 0: https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L431 llvm-svn: 337281
* [ELF] - Eliminate dead code. NFC.George Rimar2018-07-171-2/+0
| | | | | | | | | Code was dead because at the moment of BssSection creation it can never have a parent. Also, code simply does not make sence as alignment adjastment happens when BssSection is added to its parent later. llvm-svn: 337276
* [ELF] - Add classof() member for ARMExidxSentinelSection. George Rimar2018-07-111-0/+4
| | | | | | | | | | | | | | Or code uses constructions like isa<ARMExidxSentinelSection>: https://github.com/llvm-mirror/lld/blob/master/ELF/Writer.cpp#L1428 https://github.com/llvm-mirror/lld/blob/master/ELF/SyntheticSections.cpp#L2944 That is confusing, because without ARMExidxSentinelSection::classof() these lines are equal to isa<SyntheticSection> and the code does not really do the same what it expected to. I found no good way to break it though, but it is not nice. Patch adds ARMExidxSentinelSection::classof(). llvm-svn: 336813
* Parallelize GdbIndexSection's symbol table creation.Rui Ueyama2018-07-111-13/+41
| | | | | | | | | | | | | | | | | | | | | Since .gdb_index sections contain all known symbols, they can be very large. One of my executables has a .gdb_index section of 1350 GiB. Uniquifying symbols by name takes 3.77 seconds on my machine. This patch parallelize it. Time to call createSymbols() with 8.4 million unique symbols: Without this patch: 3773 ms Parallelism = 1: 4374 ms Parallelism = 2: 2628 ms Parallelism = 16: 837 ms As you can see above, this algorithm is a bit more inefficient than the non-parallelized version, but even with dual-core, it is faster than that, so I think it is overall a win. Differential Revision: https://reviews.llvm.org/D49164 llvm-svn: 336790
* Remove a workaround for an old GCC bug.Rui Ueyama2018-07-111-5/+1
| | | | | | | | | | | | | | This workaround is for GCC 5.4.1. Without this workaround, lld will produce larger .gdb_index sections for object files compiled with the buggy version of the compiler. Since it is not for correctness, and it affects only debug builds (since you are generating .gdb_index sections), perhaps the hack shouldn't have been added in the first place. At least, I think it is time to remove this hack. Differential Revision: https://reviews.llvm.org/D49149 llvm-svn: 336788
* Refactor GdbIndexSection. NFC.Rui Ueyama2018-07-101-127/+131
| | | | | | | | | | | | | | | | This patch merges createGdbIndex function and GdbIndexSection's constructor into a single static member function of the class. This patch also change how we keep CU vectors. Previously, CuVector and GdbSymbols were parallel arrays, but there's no reason to choose that design. Now, CuVector is a member of GdbSymbol class. A lot of members are removed from GdbIndexSection. Previously, it has members that need to be kept in sync over several phases. I belive the new design is less error-prone, and the new code is much easier to read than before. llvm-svn: 336743
* Simplify. NFC.Rui Ueyama2018-07-101-1/+1
| | | | llvm-svn: 336686
* Rename a variable for consistency. NFC.Rui Ueyama2018-07-101-3/+3
| | | | llvm-svn: 336674
* Reduce memory usage when creating .gdb_index. NFC.Rui Ueyama2018-07-101-84/+62
| | | | | | | | | | | | | | .gdb_index sections can be very large. When you are compiling multi-gibibyte executables, they can be larger than 1 GiB. The previous implementation of .gdb_index seems to consume too much memory. This patch reduces memory consumption by eliminating temporary objects. In one experiment, memory consumption of GdbIndexSection class is reduced from 962 MiB to 228 MiB when creating a .gdb_index of 1350 GiB. Differential Revision: https://reviews.llvm.org/D49094 llvm-svn: 336672
* Report an error for an extremely large .gdb_index section.Rui Ueyama2018-07-101-8/+10
| | | | | | | | | | I believe the only way to test this functionality is to create extremely large object files and attempt to create a .gdb_index that is greater than 4 GiB. But I think that's too much for most environments and buildbots, so I'm commiting this without a test that actually triggers the new error condition. llvm-svn: 336631
* Fix a bug for packed relocations.Rui Ueyama2018-07-091-15/+21
| | | | | | | | | Previously, we didn't create multiple consecutive bitmaps. Added a test to catch this bug too. Differential Revision: https://reviews.llvm.org/D49107 llvm-svn: 336620
* Simplify RelrSection<ELFT>::updateAllocSize.Rui Ueyama2018-07-091-40/+34
| | | | | | | | | This patch also speeds it up by making some constants compile-time constants. Other than that, NFC. Differential Revision: https://reviews.llvm.org/D49101 llvm-svn: 336614
* lld: add experimental support for SHT_RELR sections.Rui Ueyama2018-07-091-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PPC64] Add support for R_PPC64_GOT_DTPREL16* relocationsZaara Syeda2018-06-271-1/+0
| | | | | | | | | | | | | | The local dynamic TLS access on PPC64 ELF v2 ABI uses R_PPC64_GOT_DTPREL16* relocations when a TLS variables falls outside 2 GB of the thread storage block. This patch adds support for these relocations by adding a new RelExpr called R_TLSLD_GOT_OFF which emits a got entry for the TLS variable relative to the dynamic thread pointer using the relocation R_PPC64_DTPREL64. It then evaluates the R_PPC64_GOT_DTPREL16* relocations as the got offset for the R_PPC64_DTPREL64 got entries. Differential Revision: https://reviews.llvm.org/D48484 llvm-svn: 335732
* [ELF] - Change the way of sorting local symbols.George Rimar2018-06-261-13/+13
| | | | | | | | | | | | | | | | | rLLD329787 added the stable sorting to SymbolTableBaseSection::postThunkContents. I profiled the Mozilla (response-O0.txt) from lld-speed-test package and found std::stable_sort is showing up in profile results and consuming the 3.1% of the total CPU time in the RelWithDebug build. Total time of postThunkContents is 3.54%, 238ms. This change reduces postTimeContents time to 50ms, making it to take 0.73% of Total CPU time. So, instead of sorting the local part I suggest to just rebuild it. That is what this patch does. Differential revision: https://reviews.llvm.org/D45519 llvm-svn: 335583
* [ELF][MIPS] Fill a primary-GOT as much as possibleSimon Atanasyan2018-06-201-8/+13
| | | | | | | | | While building a Global Offset Table try to fill the primary GOT as much as possible because the primary GOT can be accessed in the most effective way. If it is not possible, try to fill the last GOT in the multi-GOT list, and finally create a new GOT if both attempts failed. llvm-svn: 335140
* [ELF] Support -z initfirstFangrui Song2018-06-201-0/+2
| | | | | | | | | | | | | | | | 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] Fix stable_sort predicate to satisfy strict-ordering ↵Simon Atanasyan2018-06-151-4/+6
| | | | | | | | requirement. NFC Fix for PR37785. llvm-svn: 334851
* [ELF][MIPS] Replace calls to MapVector::find by MapVector::lookup. NFCSimon Atanasyan2018-06-141-5/+5
| | | | llvm-svn: 334705
* [ELF][MIPS] Fix TLS GOT entries for local symbols in shared librariesAlexander Richardson2018-06-121-2/+14
| | | | | | | | | | | | | Summary: Previously LLD would not add any dynamic relocations and write a module index of 1 which is not correct for the shared library case. This can happen when a thread-local global variable is marked as local with a version script. With this change I am now able to link all of the FreeBSD base system for MIPS64 with LLD. Differential Revision: https://reviews.llvm.org/D48002 llvm-svn: 334483
* [ELF] Pass a pointer to InputFile to the getRelocTargetVA to escape ↵Simon Atanasyan2018-06-111-8/+8
| | | | | | dereferencing of nullptr. NFC llvm-svn: 334392
* [ELF][MIPS] Multi-GOT implementationSimon Atanasyan2018-06-111-189/+347
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [PPC64] Add lazy symbol resolution stubs.Sean Fertile2018-05-091-8/+40
| | | | | | | | | | | | | | | Adds support for .glink resolver stubs from the example implementation in the V2 ABI (Section 4.2.5.3. Procedure Linkage Table). The stubs are written to the PltSection, and the sections are renamed to match the PPC64 ABI: .got.plt --> .plt Type = SHT_NOBITS .plt --> .glink And adds the DT_PPC64_GLINK dynamic tag to the dynamic section when the plt is not empty. Differential Revision: https://reviews.llvm.org/D45642 llvm-svn: 331840
* [ELF][MIPS] Fix calculation of GP relative relocations in case of ↵Simon Atanasyan2018-05-081-5/+1
| | | | | | | | | | | | | | | | | | | relocatable output Some MIPS relocations depend on "gp" value. By default, this value has 0x7ff0 offset from a .got section. But relocatable files produced by a compiler or a linker might redefine this default value and we have to use it for a calculation of the relocation result. When we generate EXE or DSO it's trivial. Generating a relocatable output is more difficult case because the linker does calculate relocations in this case and cannot store individual "gp" values used by each input object file. As a workaround we add the "gp" value to the relocation addend. This fixes https://llvm.org/pr31149 Differential revision: https://reviews.llvm.org/D45972 llvm-svn: 331772
* Add a CIE with length 0 unconditionally.Fangrui Song2018-05-081-4/+4
| | | | | | | | | | | | Summary: This is not technically required, but glibc unwind-dw2-fde.c classify_object_over_fdes expects there is a CIE record length 0 as a terminator. Reviewers: ruiu, espindola Subscribers: emaste, arichardson, llvm-commits Differential Revision: https://reviews.llvm.org/D46566 llvm-svn: 331708
OpenPOWER on IntegriCloud