summaryrefslogtreecommitdiffstats
path: root/lld/ELF/SyntheticSections.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ELF][MIPS] Add STO_MIPS_MICROMIPS flag to symbols point to microMIPS PLT ↵Simon Atanasyan2018-05-041-2/+5
| | | | | | records llvm-svn: 331554
* Don't create a temporary DenseMap for each input .eh_frame.Rafael Espindola2018-04-271-1/+1
| | | | | | | | | | These maps are small, but we are creating an destroying one for each input .eh_frame. This patch reduces the total memory allocation from 765.54MB to 749.19MB. The peak is still the same: 563.7MB. llvm-svn: 331075
* Split .eh_frame sections in parellel.Rafael Espindola2018-04-271-5/+8
| | | | | | We can now split them in the same spot we split merge sections. llvm-svn: 331064
* Split merge sections early.Rafael Espindola2018-04-271-9/+9
| | | | | | | | | | | | | | | Now that getSectionPiece is fast (uses a hash) it is probably OK to split merge sections early. The reason I want to do this is to split eh_frame sections in the same place. This does mean that we have to decompress early. Given that the only compressed sections are debug info, I don't think we are missing much. It is a small improvement: 0.5% on the geometric mean. llvm-svn: 331058
* Replace SharedSymbols with Defined when creating copy relocations.Rafael Espindola2018-04-261-9/+5
| | | | | | | | | | | | | This is slightly simpler to read IMHO. Now if a symbol has a position in the file, it is Defined. The main motivation is that with this a SharedSymbol doesn't need a section, which reduces the size of SymbolUnion. With this the peak allocation when linking chromium goes from 568.1 to 564.2 MB. llvm-svn: 330966
* Delete GotPltIndex.Rafael Espindola2018-04-261-2/+2
| | | | | | | | | It was always an offset of PltIndex. This doesn't reduce the size of the structures, but makes it easier to do so in a followup patch. llvm-svn: 330953
* [ELF] - Never use std::sort.George Rimar2018-04-241-8/+8
| | | | | | | | | | | | | | | It turns out we should not use the std::sort anymore. r327219 added a new wrapper llvm::sort (D39245). When EXPENSIVE_CHECKS is defined, it shuffles the input container and that helps to find non-deterministic ordering. Patch changes code to use llvm::sort and std::stable_sort instead of std::sort Differential revision: https://reviews.llvm.org/D45969 llvm-svn: 330702
* Reduce code duplication.Rafael Espindola2018-04-131-6/+0
| | | | | | getVA was already implemented in the base class. llvm-svn: 330036
* [ELF][MIPS] Support linking of PIE for MIPSSimon Atanasyan2018-04-131-2/+14
| | | | | | | | | | | | | | MIPS ABI requires creation of the MIPS_RLD_MAP dynamic tag for non-PIE executables only and MIPS_RLD_MAP_REL tag for both PIE and non-PIE executables. The patch skips definition of the MIPS_RLD_MAP for PIE files and defines MIPS_RLD_MAP_REL. The MIPS_RLD_MAP_REL tag stores the offset to the .rld_map section relative to the address of the tag itself. Differential Revision: https://reviews.llvm.org/D43347 llvm-svn: 329996
* [ELF] - Reorder local symbols.George Rimar2018-04-111-3/+22
| | | | | | | | | | | This fixes PR36716 (https://bugs.llvm.org/show_bug.cgi?id=36716), Patch sorts local symbols to match the following order: file1, local1, hidden1, file2, local2, hidden2 ... Differential revision: https://reviews.llvm.org/D45325 llvm-svn: 329787
* Don't ignore addend when a SHF_MERGE section is dead.Rafael Espindola2018-04-061-3/+2
| | | | | | | | This is similar to r329219, but for the entire section. Like r329219 I don't expect this to have any real impact, it is just more consistent and simpler. llvm-svn: 329367
* Initialize OffsetMap earlier.Rafael Espindola2018-04-051-16/+8
| | | | | | | Now that getSectionPiece uses OffsetMap, it is advantageous to initialize it earlier. llvm-svn: 329242
* [ELF] - Use early return. NFC.George Rimar2018-04-041-14/+16
| | | | llvm-svn: 329180
* Inline initOffsetMap.Rafael Espindola2018-04-031-12/+17
| | | | | | | | | | | | | | | In the lld perf builder r328686 had a negative impact in stalled-cycles-frontend. Somehow that stat is not showing on my machine, but the attached patch shows an improvement on cache-misses, which is probably a reasonable proxy. My working theory is that given a large input the pieces vector is out of cache by the time initOffsetMap runs. Both finalizeContents implementation have a convenient location for initializing the OffsetMap, so this seems the best solution. llvm-svn: 329117
* ELF: Allow thunks to change size. NFCI.Peter Collingbourne2018-03-291-5/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D44962 llvm-svn: 328841
* ELF: Make required Thunk methods pure virtual and remove an unused argument. ↵Peter Collingbourne2018-03-281-2/+2
| | | | | | | | | | | NFC. Also make certain Thunk methods non-const as this will be required for an upcoming change. Differential Revision: https://reviews.llvm.org/D44961 llvm-svn: 328732
* Initialize OffsetMap in a known location.Rafael Espindola2018-03-281-1/+4
| | | | | | This is a small optimization and avoids the need to use call_once. llvm-svn: 328686
* [ELF] GotSection increment NumEntries when Target saves GlobalOffsetTable in ↵Zaara Syeda2018-03-261-3/+11
| | | | | | | | | | | | | | the .got When the target saves ElfSym::GlobalOffsetTable in the .got rather than .got.plt, Target->GotHeaderEntriesNum states the number of extra entries required in the .got. Rather than having to add Target->GotHeaderEntriesNum to NumEntries in every function which refers to NumEntries, this patch changes the initial value of NumEntries in the constructor. Differential Revision: https://reviews.llvm.org/D44744 llvm-svn: 328559
* Add a SectionBase::getVA helper. NFC.Rafael Espindola2018-03-241-7/+4
| | | | | | There were a few too many places duplicating this. llvm-svn: 328402
* Do not add a dummy entry to SharedFile::Verdefs. NFC.Rui Ueyama2018-03-241-2/+3
| | | | | | | | Previously, we used 0 as an alias for VER_NDX_GLOBAL and had a dummy entry in SharedFile::Verdefs so that the access to the array is within its boundary. But that's not straightforwad. We can just stop doing both. llvm-svn: 328401
* Fix consitent -> consistent.Eric Christopher2018-03-201-1/+1
| | | | llvm-svn: 328010
* Remove GnuHashTableSection::getShift2().Rui Ueyama2018-03-191-2/+2
| | | | | | | | | | | Choosing a Shift2 value based on wordsize is cargo-culted from gold. Assuming that djb hash is a good hash function, choosing bits [4,9] shouldn't be any worse or better than choosing bits [5,10]. We shouldn't have copied that behavior that we can't justify in the first place. Differential Revision: https://reviews.llvm.org/D44547 llvm-svn: 327921
* [ELF] Add basic support for PPC LEZaara Syeda2018-03-191-2/+6
| | | | | | | | | | | | This patch adds changes to start supporting the Power 64-Bit ELF V2 ABI. This includes: - Changing the ElfSym::GlobalOffsetTable to be named .TOC. - Creating a GotHeader so the first entry in the .got is .TOC. - Setting the e_flags to be 1 for ELF V1 and 2 for ELF V2 Differential Revision: https://reviews.llvm.org/D44483 llvm-svn: 327871
* [ELF] Recommit 327248 with Arm using the .got for _GLOBAL_OFFSET_TABLE_Peter Smith2018-03-191-2/+11
| | | | | | | | | | | | | | | | | | | | | | This is the same as 327248 except Arm defining _GLOBAL_OFFSET_TABLE_ to be the base of the .got section as some existing code is relying upon it. For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be at the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] = reserved value that is by convention the address of the dynamic section. Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end of the .got section with the intention that the .got.plt section would follow the .got. However this does not always hold with the current default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent with the reserved first entry of the .got.plt. X86, X86_64 and AArch64 will use the .got.plt. Arm, Mips and Power use .got Fixes PR36555 Differential Revision: https://reviews.llvm.org/D44259 llvm-svn: 327823
* Revert r327248, "For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is ↵Peter Collingbourne2018-03-161-11/+2
| | | | | | | | | | | expected to be at" This change broke ARM code that expects to be able to add _GLOBAL_OFFSET_TABLE_ to the result of an R_ARM_REL32. I will provide a reproducer on llvm-commits. llvm-svn: 327688
* Separate sentences to clarify a comment.Rui Ueyama2018-03-141-7/+9
| | | | llvm-svn: 327555
* [ELF] - Never create .gnu_hash with NBuckets == 0.George Rimar2018-03-141-6/+10
| | | | | | | | | | | | Currently, we can end up with NBuckets==0 and android loader does not like it (PR36537). Seems we can go with a minimal amount of changes here for simplicity and be consistent with gold and so just always use >= 1 value for NBuckets. Differential revision: https://reviews.llvm.org/D44422 llvm-svn: 327481
* For most Targets the _GLOBAL_OFFSET_TABLE_ symbol is expected to be atPeter Smith2018-03-111-2/+11
| | | | | | | | | | | | | | | | | | the start of the .got.plt section so that _GLOBAL_OFFSET_TABLE_[0] = reserved value that is by convention the address of the dynamic section. Previously we had defined _GLOBAL_OFFSET_TABLE_ as either the start or end of the .got section with the intention that the .got.plt section would follow the .got. However this does not always hold with the current default section ordering so _GLOBAL_OFFSET_TABLE_[0] may not be consistent with the reserved first entry of the .got.plt. X86, X86_64, Arm and AArch64 will use the .got.plt. Mips and Power use .got Fixes PR36555 Differential Revision: https://reviews.llvm.org/D44259 llvm-svn: 327248
* [ELF] Convert {read,write}*be to endianness-aware read/write.Fangrui Song2018-03-091-10/+8
| | | | | | | | Subscribers: emaste, nemanjai, arichardson, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D44227 llvm-svn: 327156
* Set DF_TEXTREL to executables that need text relocations.Rui Ueyama2018-03-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: If an executable needs text relocations, it should be marked as such so that the loader can prepare for text relocations. We currently create a dummy segment with DT_TEXTREL for that purpose. Generic ABI as of 2000 [1] mentioned that "Its [DT_TEXTREL's] use has been superseded by the DF_TEXTREL flag". However, it's actually not superseded even after 18 years. OpenBSD and musl recognize only DT_TEXTREL. So we still need to set both. [1] http://www.sco.com/developers/gabi/2000-07-17/ch5.dynamic.html Reviewers: rafael Subscribers: emaste, llvm-commits, arichardson Differential Revision: https://reviews.llvm.org/D43920 llvm-svn: 326503
* Merge {COFF,ELF}/Strings.cpp to Common/Strings.cpp.Rui Ueyama2018-02-281-1/+1
| | | | | | | | | This should resolve the issue that lld build fails in some hosts that uses case-insensitive file system. Differential Revision: https://reviews.llvm.org/D43788 llvm-svn: 326339
* [ELF] - Introduce getInputSections() helper.George Rimar2018-02-221-6/+3
| | | | | | | | | | | We sometimes need to iterate over input sections for a given output section. It is not very convinent because we have to iterate over section descriptions. Patch introduces getInputSections helper, it simplifies things. Differential revision: https://reviews.llvm.org/D43574 llvm-svn: 325763
* Rename DynamicReloc::getAddend() to computeAddend(). NFCAlexander Richardson2018-02-191-2/+2
| | | | | | | | | | | | | Summary: Before the name of the function sounded like it was just a getter for the private class member Addend. However, it actually calculates the final value for the r_addend field in Elf_Rela that is used when writing the .rela.dyn section. I also added a comment to the UseSymVA member to explain how it interacts with computeAddend(). Differential Revision: https://reviews.llvm.org/D43161 llvm-svn: 325485
* Simplify RelocationBaseSection::addReloc.Rafael Espindola2018-02-161-8/+4
| | | | | | | | Now that we have R_ADDEND, UseSymVA was redundant. We only want to write the symbol virtual address when using an expression other than R_ADDEND. llvm-svn: 325360
* Ensure that Elf_Rel addends are always written for dynamic relocationsAlexander Richardson2018-02-161-5/+7
| | | | | | | | | | | | Summary: This follows up on r321889 where writing of Elf_Rel addends was partially moved to RelocationBaseSection. This patch ensures that the addends are always written to the output section when a input section uses RELA but the output is REL. Differential Revision: https://reviews.llvm.org/D42843 llvm-svn: 325328
* Use RelType in a few more places. NFC.Rafael Espindola2018-02-131-2/+2
| | | | llvm-svn: 325017
* Add a simpler version of addReloc. NFC.Rafael Espindola2018-02-131-0/+5
| | | | | | Extracted from a patch by Alexander Richardson! llvm-svn: 325016
* s/uncompress/decompress/g.Rui Ueyama2018-02-121-2/+2
| | | | | | | In lld, we use both "uncompress" and "decompress" which is confusing. Since LLVM uses "decompress", we should use the same term. llvm-svn: 324944
* 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-4/+5
| | | | | | | | | | | | | | | | 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
* Simplify by sorting relocations before writing them.Rafael Espindola2018-02-011-17/+7
| | | | llvm-svn: 323944
* Use 4 as the alignment of .eh_frame_hdr.Rafael Espindola2018-01-231-1/+1
| | | | | | It includes 32 bit values and this matches both gold and bfd. llvm-svn: 323172
* Avoid divisions.Rui Ueyama2018-01-201-1/+1
| | | | | | | | Compiler doesn't know the fact that Config->WordSize * 8 is always a power of two, so it had to use the div instruction to divide some number with C. llvm-svn: 323014
* Make the bloom filter a bit larger.Rui Ueyama2018-01-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I created https://reviews.llvm.org/D42202 to see how large the bloom filter should be. With that patch, I tested various bloom filter sizes with the following commands: $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_LLD=true \ -DLLVM_ENABLE_PROJECTS='clang;lld' -DBUILD_SHARED_LIBS=ON \ -DCMAKE_SHARED_LINKER_FLAGS=-Wl,-bloom-filter-bits=<some integer> \ ../llvm-project/llvm $ rm -f $(find . -name \*.so.7.0.0svn) $ ninja lld $ LD_BIND_NOW=1 perf stat bin/ld.lld Here is the result: -bloom-filter-bits=8 0.220351609 seconds -bloom-filter-bits=10 0.217146597 seconds -bloom-filter-bits=12 0.206870826 seconds -bloom-filter-bits=16 0.209456312 seconds -bloom-filter-bits=32 0.195092075 seconds Currently we allocate 8 bits for a symbol, but according to the above result, that number is not optimal. Even though the numbers follow the diminishing return rule, the point where a marginal improvement becomes too small is not -bloom-filter-bits=8 but 12. So this patch sets it to 12. Differential Revision: https://reviews.llvm.org/D42204 llvm-svn: 323010
* Do not pass an argument that can be easily inferred from other argument.Rui Ueyama2018-01-121-2/+2
| | | | llvm-svn: 322416
* [ELF] - Do not use HeaderSize for conditions in PltSection.George Rimar2018-01-121-6/+6
| | | | | | | | | | | | | | | | Previously we checked (HeaderSize == 0) to find out if PltSection section is IPLT or PLT. Some targets does not set HeaderSize though. For example PPC64 has no lazy binding implemented and does not set PltHeaderSize constant. Because of that using of both IPLT and PLT relocations worked incorrectly there (testcase is provided). Patch fixes the issue. Differential revision: https://reviews.llvm.org/D41613 llvm-svn: 322362
* Fix thread race between SectionPiece's OutputOff and Live membersDimitry Andric2018-01-111-3/+1
| | | | | | | | | | | | | | | | | | | Summary: As reported in bug 35788, rL316280 reintroduces a race between two members of SectionPiece, which share the same 64 bit memory location. To fix the race, check the hash before checking the Live member, as suggested by Rafael. Reviewers: ruiu, rafael Reviewed By: ruiu Subscribers: smeenai, emaste, llvm-commits Differential Revision: https://reviews.llvm.org/D41884 llvm-svn: 322264
* [ELF] Fix SysV hash tables with --no-rosegmentShoaib Meenai2018-01-111-0/+3
| | | | | | | | | | | | | | When setting up the chain, we copy over the bucket's previous symbol index, assuming that this index will be 0 (STN_UNDEF) for an unused bucket (marking the end of the chain). When linking with --no-rosegment, however, unused buckets will in fact contain the padding value, and so the hash table will end up containing invalid chains. Zero out the hash table section explicitly to avoid this, similar to what's already done for GNU hash sections. Differential Revision: https://reviews.llvm.org/D41928 llvm-svn: 322259
* Centralize Config->IsRela handling.Rafael Espindola2018-01-051-0/+13
| | | | | | | This merges the two places were we check Config->IsRela to decide how to write a relocation addend. llvm-svn: 321889
* [ELF] - Add missing dynamic tags when producing output with IRelative ↵George Rimar2017-12-311-1/+7
| | | | | | | | | | | | | | | | | | | relocations only. This is "Bug 35751 - .dynamic relocation entries omitted if output contains only IFUNC relocations" We have InX::RelaPlt and InX::RelaIPlt synthetic sections for PLT relocations. They are usually live in rela.plt section. Problem appears when InX::RelaPlt section is empty. In that case we did not produce normal set of dynamic tags required, because logic was written in the way assuming we always have non-IRelative relocations in rela.plt. Patch fixes the issue. Differential revision: https://reviews.llvm.org/D41592 llvm-svn: 321600
OpenPOWER on IntegriCloud