summaryrefslogtreecommitdiffstats
path: root/lld/COFF/Chunks.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [COFF] Rename variale references in comments after VariableName -> ↵Fangrui Song2019-07-161-4/+4
| | | | | | variableName change llvm-svn: 366193
* [Coding style change][lld] Rename variables for non-ELF portsRui Ueyama2019-07-111-403/+403
| | | | | | | | | | | This patch does the same thing as r365595 to other subdirectories, which completes the naming style change for the entire lld directory. With this, the naming style conversion is complete for lld. Differential Revision: https://reviews.llvm.org/D64473 llvm-svn: 365730
* Make functions and member variables distinguishable even after the name ↵Rui Ueyama2019-07-101-1/+1
| | | | | | style change. NFC. llvm-svn: 365605
* Port r363962 to COFF: Deduplicate undefined symbol diagnosticsNico Weber2019-06-251-2/+9
| | | | | | | | | | | | | | | | | | lld/coff already deduplicated undefined symbols on a TU level: It would group all references to a symbol from a single TU. This makes it so that references from all TUs to a single symbol are grouped together. Since lld/coff almost did what I thought it did already, the patch is much smaller than the elf version. The only not local change is that getSymbolLocations() now returns a vector<string> instead of a string, so that the undefined symbol reporting code can know how many references to a symbol exist in a given TU. Fixes PR42260 for lld/coff. Differential Revision: https://reviews.llvm.org/D63646 llvm-svn: 364285
* [lld] Allow unrecognized signatures in debug sectionsReid Kleckner2019-06-121-4/+7
| | | | | | | | | | | | | | | | | | An unrecognized signature (magic) at the beginning of a debug section should not be a fatal error; it only means that the debug information is in a format that is not supported by LLD. This can be due to it being in CodeView versions 3 or earlier. These can occur in old import libraries from legacy SDKs. The test case was verified to work with MS link.exe. Patch by Vladimir Panteleev! Reviewed By: rnk Differential Revision: https://reviews.llvm.org/D63177 llvm-svn: 363212
* [COFF] Add ImportChunkThunk, simplify, deduplicateReid Kleckner2019-05-281-1/+1
| | | | | | | | | | | Removes the isHotPatchable faux-virtual and virtual methods. Follow-up to D62362. Reviewers: aganea Differential Revision: https://reviews.llvm.org/D62422 llvm-svn: 361851
* Fix 'warning: comparison is always true due to limited range of data type ↵Alexandre Ganea2019-05-281-1/+1
| | | | | | [-Wtype-limits]' with GCC 7.3 llvm-svn: 361840
* [COFF] De-virtualize Chunk and SectionChunkReid Kleckner2019-05-241-11/+6
| | | | | | | | | | | | | | | | Shaves another pointer off of SectionChunk, reducing the size from 96 to 88 bytes, down from 144 before I started working on this. Combined with D62356, this reduced peak memory usage when linking chrome_child.dll from 713MB to 675MB, or 5%. Create NonSectionChunk to provide virtual dispatch to the rest of the chunk types. Reviewers: ruiu, aganea Differential Revision: https://reviews.llvm.org/D62362 llvm-svn: 361667
* [COFF] Replace OutputSection* with uint16_t index in ChunkReid Kleckner2019-05-241-3/+2
| | | | | | | | | | | | | | Shaves another 8 bytes off of SectionChunk, the most commonly allocated type in LLD. These indices are only valid after we've assigned chunks to output sections and removed empty sections, so do that in a new pass. Reviewers: ruiu, aganea Differential Revision: https://reviews.llvm.org/D62356 llvm-svn: 361657
* [COFF] Remove finalizeContents virtual method from Chunk, NFCReid Kleckner2019-05-241-7/+8
| | | | | | | | | This only needs to be done for MergeChunks, so just do that in a separate pass in the Writer. This is one small step towards eliminating the vtable in Chunk. llvm-svn: 361573
* Re-land r361206 "[COFF] Store alignment in log2 form, NFC"Reid Kleckner2019-05-221-10/+14
| | | | | | | | | The previous patch lost the call to PowerOf2Ceil, which causes LLD to crash when handling common symbols with a non-power-of-2 size. I tweaked the existing common.test to make the bsspad16 common symbol be 15 bytes to add coverage for this case. llvm-svn: 361426
* Revert r361206 "[COFF] Store alignment in log2 form, NFC"Nico Weber2019-05-211-12/+9
| | | | | | Makes the linker crash when linking nasm.exe. llvm-svn: 361212
* [COFF] Store alignment in log2 form, NFCReid Kleckner2019-05-201-9/+12
| | | | | | | | | | | | | | | | | Summary: Valid section or chunk alignments are powers of 2 in the range [1, 8192]. These can be stored more canonically in log2 form to free up some bits in Chunk. Combined with D61696, SectionChunk gets 8 bytes smaller. Reviewers: ruiu, aganea Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61698 llvm-svn: 361206
* [Object] Change ObjectFile::getSectionContents to return ↵Fangrui Song2019-05-141-1/+1
| | | | | | | | | | | | | | | | | | | Expected<ArrayRef<uint8_t>> Change std::error_code getSectionContents(DataRefImpl, StringRef &) const; to Expected<ArrayRef<uint8_t>> getSectionContents(DataRefImpl) const; Many object formats use ArrayRef<uint8_t> as the underlying type, which is generally better than StringRef to represent binary data, so change the type to decrease the number of type conversions. Reviewed By: ruiu, sbc100 Differential Revision: https://reviews.llvm.org/D61781 llvm-svn: 360648
* [COFF] Simplify Chunk::writeTo and remove OutputSectionOff, NFCReid Kleckner2019-05-091-27/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Prior to this change, every implementation of writeTo would add OutputSectionOff to the output section buffer start before writing data. Instead, do this math in the caller, so that it can be written once instead of many times. The output section offset is always equivalent to the difference between the chunk RVA and the output section RVA, so we can replace the one remaining usage of OutputSectionOff with that subtraction. This doesn't change the size of SectionChunk because of alignment requirements, but I will rearrange the fields in a follow-up change to accomplish that. Reviewers: ruiu, aganea Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D61696 llvm-svn: 360376
* [COFF] Store Chunk RVAs and section offsets as uint32_tReid Kleckner2019-05-071-1/+1
| | | | | | | Saves 8 bytes on SectionChunk, one of the most commonly allocated data structures. llvm-svn: 360188
* Shrink SectionChunk by combining Relocs and SectionName sizesReid Kleckner2019-05-031-9/+14
| | | | | | | | | | | | | | | | | SectionChunk is one of the most frequently allocated data structures in LLD, since there are about four per function when optimizations and debug info are enabled (.text, .pdata, .xdata, .debug$S). A PE COFF file cannot be larger than 2GB, so there is an inherent limit on the length of the section name and the number of relocations. Decompose the ArrayRef and StringRef into pointer and size, and put them back together in the accessors for section name and relocation list. I plan to gather complete performance numbers later by padding SectionChunk with dead data and measuring performance after all the size optimizations are done. llvm-svn: 359923
* [Object] Change getSectionName() to return Expected<StringRef>Fangrui Song2019-05-021-1/+2
| | | | | | | | | | Summary: It currently receives an output parameter and returns std::error_code. Expected<StringRef> fits for this purpose perfectly. Differential Revision: https://reviews.llvm.org/D61421 llvm-svn: 359774
* [COFF] Reduce the size of Chunk and SectionChunk, NFCReid Kleckner2019-04-021-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reorder the fields in both to use padding more efficiently, and add more comments on the purpose of the fields. Replace `std::vector<SectionChunk*> AssociativeChildren` with a singly-linked list. This avoids the separate vector allocation to list associative children, and shrinks the 3 pointers used for the typically empty vector down to 1. In the end, this reduces the sum of heap allocations used to link browser_tests.exe with NO PDB by 13.10%, going from 2,248,728 KB to 1,954,071 KB of heap. These numbers exclude memory mapped files, which are of course a significant factor in LLD's memory usage. Reviewers: ruiu, mstorsjo, aganea Subscribers: jdoerfert, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59797 llvm-svn: 357535
* [COFF] Optimize range extension thunk insertion memory usageReid Kleckner2019-03-281-22/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This avoids allocating O(#relocs) of intermediate data for each section when range extension thunks aren't needed for that section. This also removes a std::vector from SectionChunk, which further reduces its size. Instead, this change adds the range extension thunk symbols to the object files that contain sections that need extension thunks. By adding them to the symbol table of the parent object, that means they now have a symbol table index. Then we can then modify the original relocation, after copying it to read-write memory, to use the new symbol table index. This makes linking browser_tests.exe with no PDB 10.46% faster, moving it from 11.364s to 10.288s averaged over five runs. Reviewers: mstorsjo, ruiu Subscribers: aganea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59902 llvm-svn: 357200
* [LLD][COFF] Add support for /FUNCTIONPADMIN command-line optionAlexandre Ganea2019-02-231-0/+34
| | | | | | | | | | Initial patch by Stefan Reinalter. Fixes PR36775 Differential Revision: https://reviews.llvm.org/D49366 llvm-svn: 354716
* [COFF] Create range extension thunks for ARM64Martin Storsjo2019-02-011-2/+22
| | | | | | | | | | | | | | On ARM64, this is normally necessary only after a module exceeds 128 MB in size (while the limit for thumb is 16 MB). For conditional branches, the range limit is only 1 MB though (the same as for thumb), and for the tbz instruction, the range is only 32 KB, which allows for a test much smaller than the full 128 MB. This fixes PR40467. Differential Revision: https://reviews.llvm.org/D57575 llvm-svn: 352929
* [COFF] Add support for the new relocation IMAGE_REL_ARM{,64}_REL32Martin Storsjo2019-01-271-0/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D57292 llvm-svn: 352325
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Do not assume .idata is zero-initialized.Rui Ueyama2018-11-301-0/+1
| | | | | | | | | | | | | We initialize .text section with 0xcc (INT3 instruction), so we need to explicitly write data even if it is zero if it can be in a .text section. If you specify /merge:.rdata=.text, .rdata (which contains .idata) is put to .text, so we need to do this. Fixes https://bugs.llvm.org/show_bug.cgi?id=39826 Differential Revision: https://reviews.llvm.org/D55098 llvm-svn: 348000
* [COFF] Simplify relocation to discarded section diagnostic code, NFCReid Kleckner2018-11-131-29/+36
| | | | | | Move it out of the loop that applies relocations for readability. llvm-svn: 346777
* [COFF] Improve relocation against discarded section errorReid Kleckner2018-11-081-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Reuse the "referenced by" note diagnostic code that we already use for undefined symbols. In my case, it turned this: lld-link: error: relocation against symbol in discarded section: .text lld-link: error: relocation against symbol in discarded section: .text ... Into this: lld-link: error: relocation against symbol in discarded section: .text >>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M) >>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M) ... lld-link: error: relocation against symbol in discarded section: .text >>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M) >>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M) ... I think the new output is more useful. Reviewers: ruiu, pcc Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54240 llvm-svn: 346427
* [COFF] Add and use a Wordsize field in Config. NFCI.Martin Storsjo2018-10-111-6/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D53143 llvm-svn: 344265
* [LLD][COFF] Fix ordering of CRT global initializers in COMDAT sectionsAlexandre Ganea2018-10-051-0/+7
| | | | | | | | | | (patch by Benoit Rousseau) This patch fixes a bug where the global variable initializers were sometimes not invoked in the correct order when it involved a C++ template instantiation. Differential Revision: https://reviews.llvm.org/D52749 llvm-svn: 343847
* [COFF] In MinGW mode, ignore relocations against a discarded sectionMartin Storsjo2018-09-301-1/+6
| | | | | | | | | | | | | | When GCC produces a jump table as part of a comdat function, the jump table itself is produced as plain non-comdat rdata section. When linked with ld.bfd, all of those rdata sections are kept, with relocations unchanged in the sections that refer to discarded comdat sections. This has been observed with at least GCC 5.x and 7.x. Differential Revision: https://reviews.llvm.org/D52600 llvm-svn: 343422
* [COFF] Allow automatic dllimport from gnu import librariesMartin Storsjo2018-09-261-2/+2
| | | | | | | | | Don't assume that the IAT chunk will be a DefinedImportData, it can just as well be a DefinedRegular for gnu import libraries. Differential Revision: https://reviews.llvm.org/D52381 llvm-svn: 343069
* [COFF] Add support for creating range extension thunks for ARMMartin Storsjo2018-09-251-9/+53
| | | | | | | | | | | | This is a feature that MS link.exe lacks; it currently errors out on such relocations, just like lld did before. This allows linking clang.exe for ARM - practically, any image over 16 MB will likely run into the issue. Differential Revision: https://reviews.llvm.org/D52156 llvm-svn: 342962
* [COFF] Add support for delay loading DLLs for ARM64Martin Storsjo2018-09-181-3/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D52190 llvm-svn: 342447
* [COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGWMartin Storsjo2018-09-141-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MinGW uses these kind of list terminator symbols for traversing the constructor/destructor lists. These list terminators are actual pointers entries in the lists, with the values 0 and (uintptr_t)-1 (instead of just symbols pointing to the start/end of the list). (This mechanism exists in both the mingw-w64 crt startup code and in libgcc; normally the mingw-w64 one is used, but a DLL build of libgcc uses the libgcc one. Therefore it's not trivial to change the mechanism without lots of cross-project synchronization and potentially invalidating some combinations of old/new versions of them.) When mingw-w64 has been used with lld so far, the CRT startup object files have so far provided these symbols, ending up with different, incompatible builds of the CRT startup object files depending on whether binutils or lld are going to be used. In order to avoid the need of different configuration of the CRT startup object files depending on what linker to be used, provide these symbols in lld instead. (Mingw-w64 checks at build time whether the linker provides these symbols or not.) This unifies this particular detail between the two linkers. This does disallow the use of the very latest lld with older versions of mingw-w64 (the configure check for the list was added recently; earlier it simply checked whether the CRT was built with gcc or clang), and requires rebuilding the mingw-w64 CRT. But the number of users of lld+mingw still is low enough that such a change should be tolerable, and unifies this aspect of the toolchains, easing interoperability between the toolchains for the future. The actual test for this feature is added in ctors_dtors_priority.s, but a number of other tests that checked absolute output addresses are updated. Differential Revision: https://reviews.llvm.org/D52053 llvm-svn: 342294
* [COFF] When doing automatic dll imports, replace whole .refptr.<var> chunks ↵Martin Storsjo2018-08-311-2/+2
| | | | | | | | | | | | | | | | | | | | with __imp_<var> After fixing up the runtime pseudo relocation, the .refptr.<var> will be a plain pointer with the same value as the IAT entry itself. To save a little binary size and reduce the number of runtime pseudo relocations, redirect references to the IAT entry (via the __imp_<var> symbol) itself and discard the .refptr.<var> chunk (as long as the same section chunk doesn't contain anything else than the single pointer). As there are now cases for both setting the Live variable to true and false externally, remove the accessors and setters and just make the variable public instead. Differential Revision: https://reviews.llvm.org/D51456 llvm-svn: 341175
* [COFF] Support MinGW automatic dllimport of dataMartin Storsjo2018-08-271-0/+133
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Normally, in order to reference exported data symbols from a different DLL, the declarations need to have the dllimport attribute, in order to use the __imp_<var> symbol (which contains an address to the actual variable) instead of the variable itself directly. This isn't an issue in the same way for functions, since any reference to the function without the dllimport attribute will end up as a reference to a thunk which loads the actual target function from the import address table (IAT). GNU ld, in MinGW environments, supports automatically importing data symbols from DLLs, even if the references didn't have the appropriate dllimport attribute. Since the PE/COFF format doesn't support the kind of relocations that this would require, the MinGW's CRT startup code has an custom framework of their own for manually fixing the missing relocations once module is loaded and the target addresses in the IAT are known. For this to work, the linker (originall in GNU ld) creates a list of remaining references needing fixup, which the runtime processes on startup before handing over control to user code. While this feature is rather controversial, it's one of the main features allowing unix style libraries to be used on windows without any extra porting effort. Some sort of automatic fixing of data imports is also necessary for the itanium C++ ABI on windows (as clang implements it right now) for importing vtable pointers in certain cases, see D43184 for some discussion on that. The runtime pseudo relocation handler supports 8/16/32/64 bit addresses, either PC relative references (like IMAGE_REL_*_REL32*) or absolute references (IMAGE_REL_AMD64_ADDR32, IMAGE_REL_AMD64_ADDR32, IMAGE_REL_I386_DIR32). On linking, the relocation is handled as a relocation against the corresponding IAT slot. For the absolute references, a normal base relocation is created, to update the embedded address in case the image is loaded at a different address. The list of runtime pseudo relocations contains the RVA of the imported symbol (the IAT slot), the RVA of the location the relocation should be applied to, and a size of the memory location. When the relocations are fixed at runtime, the difference between the actual IAT slot value and the IAT slot address is added to the reference, doing the right thing for both absolute and relative references. With this patch alone, things work fine for i386 binaries, and mostly for x86_64 binaries, with feature parity with GNU ld. Despite this, there are a few gotchas: - References to data from within code works fine on both x86 architectures, since their relocations consist of plain 32 or 64 bit absolute/relative references. On ARM and AArch64, references to data doesn't consist of a plain 32 or 64 bit embedded address or offset in the code. On ARMNT, it's usually a MOVW+MOVT instruction pair represented by a IMAGE_REL_ARM_MOV32T relocation, each instruction containing 16 bit of the target address), on AArch64, it's usually an ADRP+ADD/LDR/STR instruction pair with an even more complex encoding, storing a PC relative address (with a range of +/- 4 GB). This could theoretically be remedied by extending the runtime pseudo relocation handler with new relocation types, to support these instruction encodings. This isn't an issue for GCC/GNU ld since they don't support windows on ARMNT/AArch64. - For x86_64, if references in code are encoded as 32 bit PC relative offsets, the runtime relocation will fail if the target turns out to be out of range for a 32 bit offset. - Fixing up the relocations at runtime requires making sections writable if necessary, with the VirtualProtect function. In Windows Store/UWP apps, this function is forbidden. These limitations are addressed by a few later patches in lld and llvm. Differential Revision: https://reviews.llvm.org/D50917 llvm-svn: 340726
* [COFF] Check the instructions in ARM MOV32T relocationsMartin Storsjo2018-08-271-3/+9
| | | | | | | | | | For this relocation, which applies to two consecutive instructions, it's plausible that the second instruction might not actually be the right one. Differential Revision: https://reviews.llvm.org/D50998 llvm-svn: 340715
* [COFF] Move a comment close to the code it refers to. NFC.Martin Storsjo2018-08-221-3/+3
| | | | llvm-svn: 340400
* [COFF] Change fatal() into error() when writing chunks to the outputMartin Storsjo2018-08-221-15/+20
| | | | | | | | | | In most of these cases, it's easy to go on despite the error, printing as many valuable error messages as possible from one run as possible. Differential Revision: https://reviews.llvm.org/D51087 llvm-svn: 340399
* [COFF] report file containing unsupported relocationBob Haarman2018-06-071-4/+8
| | | | | | | | | | | | | | | | Summary: When reporting an unsupported relocation type, let's also report the file we encountered it in to aid diagnosis. Reviewers: ruiu, rnk Reviewed By: rnk Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45911 llvm-svn: 334154
* COFF: Allow ICFing sections with different alignments.Peter Collingbourne2018-05-141-0/+1
| | | | | | | | The combined section gets the maximum alignment of all sections. Differential Revision: https://reviews.llvm.org/D46786 llvm-svn: 332273
* [COFF] Implement the remaining ARM64 relocationsMartin Storsjo2018-05-041-5/+27
| | | | | | | | | | | Now only IMAGE_REL_ARM64_ABSOLUTE and IMAGE_REL_ARM64_TOKEN are unhandled. Also add range checks for the existing BRANCH26 relocation. Differential Revision: https://reviews.llvm.org/D46354 llvm-svn: 331505
* Fix nullptr passed to memcpy in lld/COFF/Chunks.cppBob Haarman2018-04-201-1/+2
| | | | | | | | | | | | | | | | Summary: ubsan found that we sometimes pass nullptr to memcpy in SectionChunk::writeTo(). This change adds a check that avoids that. Reviewers: ruiu Reviewed By: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45789 llvm-svn: 330490
* COFF: Preserve section type when processing /section flag.Peter Collingbourne2018-04-201-1/+1
| | | | | | | | It turns out that we were dropping this before. Differential Revision: https://reviews.llvm.org/D45802 llvm-svn: 330481
* COFF: Remove OutputSection::getPermissions() and getCharacteristics().Peter Collingbourne2018-04-191-1/+1
| | | | | | | | All callers can just access the header directly. Differential Revision: https://reviews.llvm.org/D45800 llvm-svn: 330367
* COFF: Rename Chunk::getPermissions to getOutputCharacteristics.Peter Collingbourne2018-04-191-3/+3
| | | | | | | | | | In an upcoming change I will need to make a distinction between section type (code, data, bss) and permissions. The term that I use for both of these things is "output characteristics". Differential Revision: https://reviews.llvm.org/D45799 llvm-svn: 330361
* COFF: Make SectionChunk::Relocs field an ArrayRef. NFCI.Peter Collingbourne2018-04-171-2/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D45714 llvm-svn: 330172
* COFF: Implement string tail merging.Peter Collingbourne2018-03-151-0/+42
| | | | | | | | | | | | | | | | | | In COFF, duplicate string literals are merged by placing them in a comdat whose leader symbol name contains a specific prefix followed by the hash and partial contents of the string literal. This gives us an easy way to identify sections containing string literals in the linker: check for leader symbol names with the given prefix. Any sections that are identified in this way as containing string literals may be tail merged. We do so using the StringTableBuilder class, which is also used to tail merge string literals in the ELF linker. Tail merging is enabled only if ICF is enabled, as this provides a signal as to whether the user cares about binary size. Differential Revision: https://reviews.llvm.org/D44504 llvm-svn: 327668
* Simplify.Rui Ueyama2018-02-171-5/+4
| | | | llvm-svn: 325453
* Remove an unused accessor and simplify the logic a bit. NFC.Rui Ueyama2018-02-171-4/+7
| | | | llvm-svn: 325445
OpenPOWER on IntegriCloud