summaryrefslogtreecommitdiffstats
path: root/lld/COFF/Writer.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGWMartin Storsjo2018-09-141-1/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Avoid copying of chunk vectors. NFC.Martin Storsjo2018-09-141-1/+1
| | | | | | | | | | | | When declaring the pair variable as "auto Pair : Map", it is effectively declared as std::pair<std::pair<StringRef, uint32_t>, std::vector<Chunk *>>. This effectively does a full, shallow copy of the Chunk vector, just to be thrown away after each iteration. Differential Revision: https://reviews.llvm.org/D52051 llvm-svn: 342205
* Remove an effectively unused local variable.Nico Weber2018-09-101-3/+2
| | | | llvm-svn: 341823
* lld-link: Write an empty "repro" debug directory entry if /Brepro is passedNico Weber2018-09-051-18/+36
| | | | | | | | | | | If the coff timestamp is set to a hash, like lld-link does if /Brepro is passed, the coff spec suggests that a IMAGE_DEBUG_TYPE_REPRO entry is in the debug directory. This lets lld-link write such a section. Fixes PR38429, see bug for details. Differential Revision: https://reviews.llvm.org/D51652 llvm-svn: 341486
* [COFF] When doing automatic dll imports, replace whole .refptr.<var> chunks ↵Martin Storsjo2018-08-311-4/+4
| | | | | | | | | | | | | | | | | | | | 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/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Make the relocation scanning for CFG more discriminatingHans Wennborg2018-08-091-7/+13
| | | | | | | | | link.exe ignores REL32 relocations on 32-bit x86, as well as relocations against non-function symbols such as labels. This makes lld do the same. Differential Revision: https://reviews.llvm.org/D50430 llvm-svn: 339345
* [COFF] Sort .reloc before all other discardable sectionsMartin Storsjo2018-07-201-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a binary is stripped, which can remove discardable sections (except for the .reloc section, which also is marked as discardable as it isn't loaded at runtime, only read by the loader), the .reloc section should be first of them, in order not to create gaps in the image. Previously, binaries with relocations were broken if they were stripped by GNU binutils strip. Trying to execute such binaries produces an error about "xx is not a valid win32 application". This fixes GNU binutils bug 23348. Prior to SVN r329370 (which didn't intend to have functional changes), the code for moving discardable sections to the end didn't clearly express how other discardable sections should be ordered compared to .reloc, but the change retained the exact same end result as before. After SVN r329370, the code (and comments) more clearly indicate that it tries to make the .reloc section the absolutely last one; this patch changes that. This matches how GNU binutils ld sorts .reloc compared to dwarf debug info sections. Differential Revision: https://reviews.llvm.org/D49351 Signed-off-by: Martin Storsjö <martin@martin.st> llvm-svn: 337598
* [COFF] Write the debug directory and build id to a separate section for MinGWMartin Storsjo2018-07-201-2/+6
| | | | | | | | | | | | | | | | | For dwarf debug info, an executable normally either contains the debug info, or it is stripped out. To reduce the storage needed (slightly) for the debug info kept separately from the released, stripped binaries, one can choose to only copy the debug data from the original executable (essentially the reverse of the strip operation), producing a file with only debug info. When copying the debug data from an executable with GNU objcopy, the build id and debug directory need to reside in a separate section, as this will be kept while the rest of the .rdata section is removed. Differential Revision: https://reviews.llvm.org/D49352 llvm-svn: 337526
* [COFF] Don't produce base relocs for discardable sectionsMartin Storsjo2018-07-191-1/+1
| | | | | | | | | | | | | Dwarf debug info contains some data that contains absolute addresses. Since these sections are discardable and aren't loaded at runtime, there's no point in adding base relocations for them. This makes sure that after stripping out dwarf debug info, there are no base relocations that point to nonexistent sections. Differential Revision: https://reviews.llvm.org/D49350 llvm-svn: 337438
* [coff] remove_dots from /PDBPATH but not /PDBALTPATH.Zachary Turner2018-07-121-7/+4
| | | | | | | This more closely matches the behavior of link.exe, and also simplifies the code slightly. llvm-svn: 336882
* [coff] Remove dots in path pointing to PDB file.Zachary Turner2018-07-121-4/+7
| | | | | | | | | | | Some Microsoft tools (e.g. new versions of WPA) fail when the COFF Debug Directory contains a path to the PDB that contains dots, such as D:\foo\./bar.pdb. Remove dots before writing this path. This fixes pr38126. llvm-svn: 336873
* [COFF] Store import symbol pointers as pointers to the base classMartin Storsjo2018-07-101-4/+11
| | | | | | | | | | | | | | | Future symbol insertions can potentially change the type of these symbols - keep pointers to the base class to reflect this, and use dynamic casts to inspect them before using as the subclass type. This fixes crashes that were possible before, by touching these symbols that now are populated as e.g. a DefinedRegular, via the old pointers with DefinedImportThunk type. Differential Revision: https://reviews.llvm.org/D48953 llvm-svn: 336652
* [COFF] Add an LLD specific option -debug:symbtabMartin Storsjo2018-06-291-1/+1
| | | | | | | | | | | With this set, we retain the symbol table, but skip the actual debug information. This is meant to be used by the MinGW frontend. Differential Revision: https://reviews.llvm.org/D48745 llvm-svn: 335946
* lld-link: align sections to 16 bytes if referenced from the gfids tableBob Haarman2018-06-281-0/+5
| | | | | | | | | | | | | | | | | | | Summary: Control flow guard works best when targets it checks are 16-byte aligned. Microsoft's link.exe helps ensure this by aligning code from sections that are referenced from the gfids table to 16 bytes when linking with -guard:cf, even if the original section specifies a smaller alignment. This change implements that behavior in lld-link. See https://crbug.com/857012 for more details. Reviewers: ruiu, hans, thakis, zturner Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D48690 llvm-svn: 335864
* [COFF] Fix crash when emitting symbol tables with GCShoaib Meenai2018-06-121-1/+4
| | | | | | | | | | | | | When running with linker GC (`-opt:ref`), defined imported symbols that are referenced but then dropped by GC end up with their `Location` member being nullptr, which means `getChunk()` returns nullptr for them and attempting to call `getChunk()->getOutputSection()` causes a crash from the nullptr dereference. Check for `getChunk()` being nullptr and bail out early to avoid the crash. Differential Revision: https://reviews.llvm.org/D48092 llvm-svn: 334548
* lld-link: Implement /INTEGRITYCHECK flagNico Weber2018-05-311-0/+2
| | | | | | | | /INTEGRITYCHECK has the effect of setting IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY. Fixes PR31066. https://reviews.llvm.org/D47472 llvm-svn: 333652
* [COFF] Unify output section code. NFCShoaib Meenai2018-05-291-22/+17
| | | | | | | | | | Peter Collingbourne suggested moving the switch to the top of the function, so that all the code that cares about the output section for a symbol is in the same place. Differential Revision: https://reviews.llvm.org/D47497 llvm-svn: 333472
* [COFF] Simplify symbol table output section computationShoaib Meenai2018-05-291-14/+9
| | | | | | | | | | | | | | | | | | | | | Rather than using a loop to compare symbol RVAs to the starting RVAs of sections to determine which section a symbol belongs to, just get the output section of a symbol directly via its chunk, and bail if the symbol doesn't have an output section, which avoids having to hardcode logic for handling dead symbols, CodeView symbols, etc. This was suggested by Reid Kleckner; thank you. This also fixes writing out symbol tables in the presence of RVA table input sections (e.g. .sxdata and .gfids). Such sections aren't written to the output file directly, so their RVA is 0, and the loop would thus fail to find an output section for them, resulting in a segfault. Extend some existing tests to cover this case. Fixes PR37584. Differential Revision: https://reviews.llvm.org/D47391 llvm-svn: 333450
* [COFF] Add /Brepro and /TIMESTAMP options.Zachary Turner2018-05-171-3/+5
| | | | | | | | | | | | | | | | | | | | Previously we would always write a hash of the binary into the PE file, for reproducible builds. This breaks AppCompat, which is a feature of Windows that relies on the timestamp in the PE header being set to a real value (or at the very least, a value that satisfies certain properties). To address this, we put the old behavior of writing the hash behind the /Brepro flag, which mimics MSVC linker behavior. We also match MSVC default behavior, which is to write an actual timestamp to the PE header. Finally, we add the /TIMESTAMP option (an lld extension) so that the user can specify the exact value to be used in case he/she manually constructs a value which is both reproducible and satisfies AppCompat. Differential Revision: https://reviews.llvm.org/D46966 llvm-svn: 332613
* COFF: Don't create unnecessary thunks.Peter Collingbourne2018-05-101-6/+2
| | | | | | | | | A thunk is only needed if a relocation points to the undecorated import name. Differential Revision: https://reviews.llvm.org/D46673 llvm-svn: 332019
* COFF: Preserve section type when processing /section flag.Peter Collingbourne2018-04-201-1/+2
| | | | | | | | It turns out that we were dropping this before. Differential Revision: https://reviews.llvm.org/D45802 llvm-svn: 330481
* COFF: Use (name, output characteristics) as a key when grouping input ↵Peter Collingbourne2018-04-201-28/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sections into output sections. This is what link.exe does and lets us avoid needing to worry about merging output characteristics while adding input sections to output sections. With this change we can't process /merge in the same way as before because sections with different output characteristics can still be merged into one another. So this change moves the processing of /merge to just before we assign addresses. In the case where there are multiple output sections with the same name, link.exe only merges the first section with the source name into the first section with the target name, and we do the same. At the same time I also implemented transitive merging (which means that /merge:.c=.b /merge:.b=.a merges both .c and .b into .a). This isn't quite enough though because link.exe has a special case for .CRT in 32-bit mode: it processes sections whose output characteristics are DATA | R | W as though the output characteristics were DATA | R (so that they get merged into things like constructor lists in the expected way). Chromium has a few such sections, and it turns out that those sections were causing the problem that resulted in r318699 (merge .xdata into .rdata) being reverted: because of the previous permission merging semantics, the .CRT sections were causing the entire .rdata section to become writable, which caused the SEH runtime to crash because it apparently requires .xdata to be read-only. This change also implements the same special case. This should unblock being able to merge .xdata into .rdata by default, as well as .bss into .data, both of which will be done in followups. Differential Revision: https://reviews.llvm.org/D45801 llvm-svn: 330479
* COFF: Remove OutputSection::getPermissions() and getCharacteristics().Peter Collingbourne2018-04-191-5/+5
| | | | | | | | 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-1/+1
| | | | | | | | | | 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] Mark images with no exception handlers for /safesehReid Kleckner2018-04-181-4/+12
| | | | | | | | | | | | | | | | | Summary: DLLs and executables with no exception handlers need to be marked with IMAGE_DLL_CHARACTERISTICS_NO_SEH, even if they have a load config. Discovered here when building Chromium with LLD on Windows: https://crbug.com/833951 Reviewers: ruiu, mstorsjo Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45778 llvm-svn: 330300
* COFF: Implement /pdbaltpath flag.Peter Collingbourne2018-04-171-11/+4
| | | | | | | | | | | I needed to revert r330223 because we were embedding an absolute PDB path in the .rdata section, which ended up being laid out before the .idata section and affecting its RVAs. This flag will let us control the embedded path. Differential Revision: https://reviews.llvm.org/D45747 llvm-svn: 330232
* COFF: Process /merge flag as we create output sections.Peter Collingbourne2018-04-071-26/+43
| | | | | | | | With this we can merge builtin sections. Differential Revision: https://reviews.llvm.org/D45350 llvm-svn: 329471
* COFF: Create output sections early. NFCI.Peter Collingbourne2018-04-061-126/+119
| | | | | | | | | With this, all output sections are created in one place. This will make it simpler to implement merging of builtin sections. Differential Revision: https://reviews.llvm.org/D45349 llvm-svn: 329370
* COFF: Sort non-discardable sections at the same time as other sections. NFC.Peter Collingbourne2018-04-041-9/+8
| | | | | | | | This makes the sort order a little clearer. Differential Revision: https://reviews.llvm.org/D45282 llvm-svn: 329227
* COFF: Layout sections in the same order as link.exeHans Wennborg2018-04-041-0/+25
| | | | | | | | | | | | One place where this seems to matter is to make sure the .rsrc section comes after .text. The Win32 UpdateResource() function can change the contents of .rsrc. It will move the sections that come after, but if .text gets moved, the entry point header will not get updated and the executable breaks. This was found by a test in Chromium. Differential Revision: https://reviews.llvm.org/D45260 llvm-svn: 329221
* [COFF] Clarify comment. NFCShoaib Meenai2018-03-161-6/+8
| | | | | | | | | | | Reid pointed out the string table for supporting long section names is a BFD extension and the comments should reflect that. Explicitly spell out link.exe's and binutil's behavior around section names and the rationale for LLD's behavior. Differential Revision: https://reviews.llvm.org/D42659 llvm-svn: 327736
* COFF: Implement string tail merging.Peter Collingbourne2018-03-151-0/+4
| | | | | | | | | | | | | | | | | | 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
* COFF: Move assignment of section RVAs to assignAddresses(). NFCI.Peter Collingbourne2018-03-151-37/+22
| | | | | | | | | | This makes the design a little more similar to the ELF linker and should allow for features such as ARM range extension thunks to be implemented more easily. Differential Revision: https://reviews.llvm.org/D44501 llvm-svn: 327667
* Resubmit "Write a hash of the executable into the PE timestamp fields."Zachary Turner2018-03-081-14/+50
| | | | | | | | | This fixes the broken tests that were causing failures. The tests before were verifying that the time stamp was 0, but now that we are actually writing a timestamp, I just removed the match against the timestamp value. llvm-svn: 327049
* [COFF] Make the DOS stub a real DOS programHans Wennborg2018-03-081-3/+47
| | | | | | | | It only adds a few bytes and is nice for backward compatibility. Differential Revision: https://reviews.llvm.org/D44018 llvm-svn: 327001
* Revert "Write a hash of the executable into the PE timestamp fields."Zachary Turner2018-03-071-50/+14
| | | | | | | This is breaking a couple of tests, so I'm reverting temporarily until I can get everything resolved properly. llvm-svn: 326943
* Write a hash of the executable into the PE timestamp fields.Zachary Turner2018-03-071-14/+50
| | | | | | | | | | | | | | | | Windows tools treats the timestamp fields as sort of a build id, using it to archive executables on a symbol server, as well as for matching executables to PDBs. We were writing 0 for these fields, which would cause symbol servers to break as they are indexed in the symbol server based on this value. Although the field is called timestamp, it can really be any value that is unique per build, so to support reproducible builds we use a hash of the executable here. Differential Revision: https://reviews.llvm.org/D43978 llvm-svn: 326920
* Remove an unused accessor and simplify the logic a bit. NFC.Rui Ueyama2018-02-171-3/+3
| | | | llvm-svn: 325445
* [LLD] Implement /guard:[no]longjmpReid Kleckner2018-02-131-12/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This protects calls to longjmp from transferring control to arbitrary program points. Instead, longjmp calls are limited to the set of registered setjmp return addresses. This also implements /guard:nolongjmp to allow users to link in object files that call setjmp that weren't compiled with /guard:cf. In this case, the linker will approximate the set of address taken functions, but it will leave longjmp unprotected. I used the following program to test, compiling it with different -guard flags: $ cl -c t.c -guard:cf $ lld-link t.obj -guard:cf #include <setjmp.h> #include <stdio.h> jmp_buf buf; void g() { printf("before longjmp\n"); fflush(stdout); longjmp(buf, 1); } void f() { if (setjmp(buf)) { printf("setjmp returned non-zero\n"); return; } g(); } int main() { f(); printf("hello world\n"); } In particular, the program aborts when the code is compiled *without* -guard:cf and linked with -guard:cf. That indicates that longjmps are protected. Reviewers: ruiu, inglorion, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43217 llvm-svn: 325047
* [COFF] Add minimal support for /guard:cfReid Kleckner2018-02-061-22/+150
| | | | | | | | | | | | | | | | | | | Summary: This patch adds some initial support for Windows control flow guard. At the end of the day, the linker needs to synthesize a table of RVAs very similar to the structured exception handler table (/safeseh). Both /safeseh and /guard:cf take sections of symbol table indices (.sxdata and .gfids$y) and turn them into RVA tables referenced by the load config struct in the CRT through special symbols. Reviewers: ruiu, amccarth Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D42592 llvm-svn: 324306
* [COFF] Update comment to reflect link.exe behavior. NFCShoaib Meenai2018-01-271-3/+2
| | | | | | | | | | In my experimentation with link.exe from both VS 2015 and 2017, it always produces images with truncated section names. Update the comment accordingly. Differential Revision: https://reviews.llvm.org/D42603 llvm-svn: 323598
* Add the /order option.Rui Ueyama2018-01-271-0/+20
| | | | | | | | | | | | With the /order option, you can give an order file. An order file contains symbol names, one per line, and the linker places comdat sections in that given order. The option is used often to optimize an output binary for (in particular, startup) speed by improving locality. Differential Revision: https://reviews.llvm.org/D42598 llvm-svn: 323579
* [coff] Print detailed timing information with /TIME.Zachary Turner2018-01-171-1/+9
| | | | | | | | | The classes used to print and update time information are in common, so other linkers could use this as well if desired. Differential Revision: https://reviews.llvm.org/D41915 llvm-svn: 322736
* [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB)Rui Ueyama2018-01-171-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch by Colden Cullen. Currently, when a large PE (>4 GiB) is to be produced, a crash occurs because: 1. Calling setOffset with a number greater than UINT32_MAX causes the PointerToRawData to overflow 2. When adding the symbol table to the end of the file, the last section's offset was used to calculate file size. Because this had overflowed, this number was too low, and the file created would not be large enough. This lead to the actual crash I saw, which was a buffer overrun. This change: 1. Adds comment to setOffset, clarifying that overflow can occur, but it's somewhat safe because the error will be handled elsewhere 2. Adds file size check after all output data has been created This matches the MS link.exe error, which looks prints as: "LINK : fatal error LNK1248: image size (10000EFC9) exceeds maximum allowable size (FFFFFFFF)" 3. Changes calculate of the symbol table offset to just use the existing FileSize. This should match the previous calculations, but doesn't rely on the use of a u32 that can overflow. 4. Removes trivial usage of a magic number that bugged me while I was debugging the issue I'm not sure how to add a test for this outside of adding 4GB of object files to the repo. If there's an easier way, let me know and I'll be happy to add a test. Differential Revision: https://reviews.llvm.org/D42010 llvm-svn: 322605
* [COFF] Set the IMAGE_DLL_CHARACTERISTICS_NO_SEH flag automaticallyMartin Storsjo2017-12-151-0/+3
| | | | | | | | This seems to match how link.exe sets it. Differential Revision: https://reviews.llvm.org/D41252 llvm-svn: 320860
* [COFF] Sort .pdata for arm64Martin Storsjo2017-12-141-1/+1
| | | | | | | | | | This works for linking the output from the MSVC compiler. The pdata entries for arm64 seem to be 8 bytes in the same (or at least similar) form to arm. Differential Revision: https://reviews.llvm.org/D41160 llvm-svn: 320676
* Always evaluate the second argument for CHECK() lazily.Rui Ueyama2017-12-061-1/+1
| | | | | | | | | This patch is to rename check CHECK and make it a C macro, so that we can evaluate the second argument lazily. Differential Revision: https://reviews.llvm.org/D40915 llvm-svn: 319974
* COFF: Simplify construction of safe SEH table. NFCI.Peter Collingbourne2017-11-281-5/+4
| | | | | | | | | Instead of building intermediate sets of exception handlers for each object file, just create one for the final output file. Differential Revision: https://reviews.llvm.org/D40581 llvm-svn: 319244
* Move Memory.{h,cpp} to Common.Rui Ueyama2017-11-281-1/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D40571 llvm-svn: 319221
OpenPOWER on IntegriCloud