Commit Graph

242 Commits

Author SHA1 Message Date
Martin Storsjo 57ddec0dd1 [COFF] Add support for creating range extension thunks for ARM
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
2018-09-25 10:59:29 +00:00
Martin Storsjo 5f6d527f09 [COFF] Support linking to import libraries from GNU binutils
GNU binutils import libraries aren't the same kind of short import
libraries as link.exe and LLD produce, but are a plain static library
containing .idata section chunks. MSVC link.exe can successfully link
to them.

In order for imports from GNU import libraries to mix properly with the
normal import chunks, the chunks from the existing mechanism needs to
be added into named sections like .idata$2.

These GNU import libraries consist of one header object, a number of
object files, one for each imported function/variable, and one trailer.
Within the import libraries, the object files are ordered alphabetically
in this order. The chunks stemming from these libraries have to be
grouped by what library they originate from and sorted, to make sure
the section chunks for headers and trailers for the lists are ordered
as intended. This is done on all sections named .idata$*, before adding
the synthesized chunks to them.

Differential Revision: https://reviews.llvm.org/D38513

llvm-svn: 342777
2018-09-21 22:01:06 +00:00
Nico Weber 0bd2d304e6 lld-link: Set PDB GUID to hash of PDB contents instead of to a random byte sequence.
Previously, lld-link would use a random byte sequence as the PDB GUID. Instead,
use a hash of the PDB file contents.

To not disturb llvm-pdbutil pdb2yaml, the hash generation is an opt-in feature
on InfoStreamBuilder and ldb/COFF/PDB.cpp always sets it.

Since writing the PDB computes this ID which also goes in the exe, the PDB
writing code now must be called before writeBuildId(). writeBuildId() for that
reason is no longer included in the "Code Layout" timer.

Since the PDB GUID is now a function of the PDB contents, the PDB Age is always
set to 1. There was a long comment above loadExistingBuildId (now gone) about
how not changing the GUID and only incrementing the age was important, but
according to the discussion in PR35914 that comment was incorrect.

Differential Revision: https://reviews.llvm.org/D51956

llvm-svn: 342334
2018-09-15 18:37:22 +00:00
Martin Storsjo 7a41693898 [COFF] Provide __CTOR_LIST__ and __DTOR_LIST__ symbols for MinGW
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
2018-09-14 22:26:59 +00:00
Martin Storsjo 4c201a8ba5 [COFF] Avoid copying of chunk vectors. NFC.
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
2018-09-14 06:08:51 +00:00
Nico Weber cc08366035 Remove an effectively unused local variable.
llvm-svn: 341823
2018-09-10 13:20:16 +00:00
Nico Weber 13b55bbc2f lld-link: Write an empty "repro" debug directory entry if /Brepro is passed
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
2018-09-05 18:02:43 +00:00
Martin Storsjo 802fcb4167 [COFF] When doing automatic dll imports, replace whole .refptr.<var> chunks 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
2018-08-31 07:45:20 +00:00
Martin Storsjo eac1b05f1d [COFF] Support MinGW automatic dllimport of data
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
2018-08-27 08:43:31 +00:00
Hans Wennborg bdd8493f2b [COFF] Make the relocation scanning for CFG more discriminating
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
2018-08-09 13:43:22 +00:00
Martin Storsjo 98ff9f845d [COFF] Sort .reloc before all other discardable sections
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
2018-07-20 18:43:35 +00:00
Martin Storsjo a55fc71614 [COFF] Write the debug directory and build id to a separate section for MinGW
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
2018-07-20 05:44:34 +00:00
Martin Storsjo c35e4bf7eb [COFF] Don't produce base relocs for discardable sections
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
2018-07-19 04:25:22 +00:00
Zachary Turner e2ce2a5c86 [coff] remove_dots from /PDBPATH but not /PDBALTPATH.
This more closely matches the behavior of link.exe, and also
simplifies the code slightly.

llvm-svn: 336882
2018-07-12 03:22:39 +00:00
Zachary Turner bf9abccacd [coff] Remove dots in path pointing to PDB file.
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
2018-07-12 00:44:15 +00:00
Martin Storsjo 474be005db [COFF] Store import symbol pointers as pointers to the base class
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
2018-07-10 10:40:11 +00:00
Martin Storsjo 3a7905b2aa [COFF] Add an LLD specific option -debug:symbtab
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
2018-06-29 06:08:25 +00:00
Bob Haarman c103156c60 lld-link: align sections to 16 bytes if referenced from the gfids table
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
2018-06-28 15:22:40 +00:00
Shoaib Meenai 02c4344262 [COFF] Fix crash when emitting symbol tables with GC
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
2018-06-12 21:19:33 +00:00
Nico Weber d657c25649 lld-link: Implement /INTEGRITYCHECK flag
/INTEGRITYCHECK has the effect of setting
IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY. Fixes PR31066.
https://reviews.llvm.org/D47472

llvm-svn: 333652
2018-05-31 13:43:02 +00:00
Shoaib Meenai 663518d61a [COFF] Unify output section code. NFC
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
2018-05-29 22:49:56 +00:00
Shoaib Meenai 4e51833611 [COFF] Simplify symbol table output section computation
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
2018-05-29 19:07:47 +00:00
Zachary Turner c8dd6ccc8a [COFF] Add /Brepro and /TIMESTAMP options.
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
2018-05-17 15:11:01 +00:00
Peter Collingbourne e28faed768 COFF: Don't create unnecessary thunks.
A thunk is only needed if a relocation points to the undecorated
import name.

Differential Revision: https://reviews.llvm.org/D46673

llvm-svn: 332019
2018-05-10 19:01:28 +00:00
Peter Collingbourne 71c7de5b77 COFF: Preserve section type when processing /section flag.
It turns out that we were dropping this before.

Differential Revision: https://reviews.llvm.org/D45802

llvm-svn: 330481
2018-04-20 21:23:16 +00:00
Peter Collingbourne 381b3d8aa3 COFF: Use (name, output characteristics) as a key when grouping input 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
2018-04-20 21:10:33 +00:00
Peter Collingbourne be084eca5b COFF: Remove OutputSection::getPermissions() and getCharacteristics().
All callers can just access the header directly.

Differential Revision: https://reviews.llvm.org/D45800

llvm-svn: 330367
2018-04-19 21:48:37 +00:00
Peter Collingbourne fa322abee9 COFF: Rename Chunk::getPermissions to getOutputCharacteristics.
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
2018-04-19 20:03:24 +00:00
Reid Kleckner 8f1a28f190 [COFF] Mark images with no exception handlers for /safeseh
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
2018-04-18 22:37:10 +00:00
Peter Collingbourne 94aa62e48a COFF: Implement /pdbaltpath flag.
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
2018-04-17 23:28:38 +00:00
Peter Collingbourne 4902508934 COFF: Process /merge flag as we create output sections.
With this we can merge builtin sections.

Differential Revision: https://reviews.llvm.org/D45350

llvm-svn: 329471
2018-04-07 00:46:55 +00:00
Peter Collingbourne f2c0f39b91 COFF: Create output sections early. NFCI.
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
2018-04-06 03:25:49 +00:00
Peter Collingbourne 05f0bae318 COFF: Sort non-discardable sections at the same time as other sections. NFC.
This makes the sort order a little clearer.

Differential Revision: https://reviews.llvm.org/D45282

llvm-svn: 329227
2018-04-04 20:30:37 +00:00
Hans Wennborg 9a9fc78744 COFF: Layout sections in the same order as link.exe
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
2018-04-04 19:15:55 +00:00
Shoaib Meenai 290f26fefd [COFF] Clarify comment. NFC
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
2018-03-16 20:20:01 +00:00
Peter Collingbourne f1a11f87a0 COFF: Implement string tail merging.
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
2018-03-15 21:14:02 +00:00
Peter Collingbourne 435b099115 COFF: Move assignment of section RVAs to assignAddresses(). NFCI.
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
2018-03-15 21:13:46 +00:00
Zachary Turner b575f46b6d Resubmit "Write a hash of the executable into the PE timestamp fields."
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
2018-03-08 19:33:47 +00:00
Hans Wennborg aee5881a85 [COFF] Make the DOS stub a real DOS program
It only adds a few bytes and is nice for backward compatibility.

Differential Revision: https://reviews.llvm.org/D44018

llvm-svn: 327001
2018-03-08 14:27:28 +00:00
Zachary Turner 0b4af0434b Revert "Write a hash of the executable into the PE timestamp fields."
This is breaking a couple of tests, so I'm reverting temporarily
until I can get everything resolved properly.

llvm-svn: 326943
2018-03-07 21:22:10 +00:00
Zachary Turner 69f3347b56 Write a hash of the executable into the PE timestamp fields.
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
2018-03-07 18:13:41 +00:00
Rui Ueyama b3107476a4 Remove an unused accessor and simplify the logic a bit. NFC.
llvm-svn: 325445
2018-02-17 20:41:38 +00:00
Reid Kleckner fd52096259 [LLD] Implement /guard:[no]longjmp
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
2018-02-13 20:32:53 +00:00
Reid Kleckner af2f7da74c [COFF] Add minimal support for /guard:cf
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
2018-02-06 01:58:26 +00:00
Shoaib Meenai 34a1101b06 [COFF] Update comment to reflect link.exe behavior. NFC
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
2018-01-27 18:17:08 +00:00
Rui Ueyama 57175aa1e9 Add the /order option.
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
2018-01-27 00:34:46 +00:00
Zachary Turner 727f153b6f [coff] Print detailed timing information with /TIME.
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
2018-01-17 19:16:26 +00:00
Rui Ueyama 2c95e798a0 [LLD][COFF] Report error when file will exceed Windows maximum image size (4GB)
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
2018-01-17 01:08:02 +00:00
Martin Storsjo a1e9b6e3d2 [COFF] Set the IMAGE_DLL_CHARACTERISTICS_NO_SEH flag automatically
This seems to match how link.exe sets it.

Differential Revision: https://reviews.llvm.org/D41252

llvm-svn: 320860
2017-12-15 20:53:03 +00:00
Martin Storsjo 9603b8e3f5 [COFF] Sort .pdata for arm64
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
2017-12-14 08:56:29 +00:00