Commit Graph

116 Commits

Author SHA1 Message Date
Andrew Paverd 0139c8af8d [CFGuard] Add address-taken IAT tables and delay-load support
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D87544
2020-11-17 18:24:45 -08:00
Hans Wennborg 418f18c6cd Revert "Reland [CFGuard] Add address-taken IAT tables and delay-load support"
This broke both Firefox and Chromium (PR47905) due to what seems like dllimport
function not being handled correctly.

> This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
> Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.
>
> Reviewed By: rnk
>
> Differential Revision: https://reviews.llvm.org/D87544

This reverts commit cfd8481da1.
2020-11-11 16:03:33 +01:00
Martin Storsjö 3785a413fe Reapply [LLD] [COFF] Implement a GNU/ELF like -wrap option
Add a simple forwarding option in the MinGW frontend, and implement
the private -wrap option in the COFF linker.

The feature in lld-link isn't gated by the -lldmingw option, but
the option is left as a private, undocumented option primarily
used by the MinGW driver.

The implementation is significantly based on the support for --wrap
in the ELF linker, but many small nuance details are different
between the ELF and COFF linkers, ending up with more than a few
implementation differences.

This fixes https://bugs.llvm.org/show_bug.cgi?id=47384.

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

Reapplied with the bitfield member canInline fixed so it doesn't break
builds targeting windows.
2020-10-15 22:14:02 +03:00
Arthur Eubanks 3d338f6813 Revert "[LLD] [COFF] Implement a GNU/ELF like -wrap option"
This reverts commit a012c704b5.

Breaks Windows builds.

C:\src\llvm-mint\lld\COFF\Symbols.cpp(26,1): error: static_assert failed due to requirement 'sizeof(lld::coff::SymbolUnion) <= 48' "symbols should be optimized for memory usage"
static_assert(sizeof(SymbolUnion) <= 48,
2020-10-15 10:27:25 -07:00
Martin Storsjö a012c704b5 [LLD] [COFF] Implement a GNU/ELF like -wrap option
Add a simple forwarding option in the MinGW frontend, and implement
the private -wrap option in the COFF linker.

The feature in lld-link isn't gated by the -lldmingw option, but
the option is left as a private, undocumented option primarily
used by the MinGW driver.

The implementation is significantly based on the support for --wrap
in the ELF linker, but many small nuance details are different
between the ELF and COFF linkers, ending up with more than a few
implementation differences.

This fixes https://bugs.llvm.org/show_bug.cgi?id=47384.

Differential Revision: https://reviews.llvm.org/D89004
2020-10-15 18:34:02 +03:00
Andrew Paverd cfd8481da1 Reland [CFGuard] Add address-taken IAT tables and delay-load support
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D87544
2020-10-13 13:20:52 -07:00
Arthur Eubanks 499260c03b Revert "[CFGuard] Add address-taken IAT tables and delay-load support"
This reverts commit ef4e971e5e.
2020-10-01 11:29:54 -07:00
Andrew Paverd ef4e971e5e [CFGuard] Add address-taken IAT tables and delay-load support
This patch adds support for creating Guard Address-Taken IAT Entry Tables (.giats$y sections) in object files, matching the behavior of MSVC. These contain lists of address-taken imported functions, which are used by the linker to create the final GIATS table.
Additionally, if any DLLs are delay-loaded, the linker must look through the .giats tables and add the respective load thunks of address-taken imports to the GFIDS table, as these are also valid call targets.

Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D87544
2020-10-01 12:45:07 +01:00
Reid Kleckner 9b7f6146bd [COFF] Paritally inline Symbol::getName, NFC 2020-05-03 07:58:05 -07:00
Martin Storsjö 78ce19b7e1 [LLD] [COFF] Fix post-commit suggestions for absolute symbol equality
Differential Revision: https://reviews.llvm.org/D72252
2020-01-08 22:10:05 +02:00
Martin Storsjö 1737cc750c [LLD] [COFF] Don't error out on duplicate absolute symbols with the same value
Both MS link.exe and GNU ld.bfd handle it this way; one can have
multiple object files defining the same absolute symbols, as long
as it defines it to the same value. But if there are multiple absolute
symbols with differing values, it is treated as an error.

Differential Revision: https://reviews.llvm.org/D71981
2020-01-04 12:29:33 +02:00
Bob Haarman 7dc5e7a0a4 reland "[lld-link] implement -start-lib and -end-lib"
Summary:
This is a re-land of r370487 with a fix for the use-after-free bug
that rev contained.

This implements -start-lib and -end-lib flags for lld-link, analogous
to the similarly named options in ld.lld. Object files after
-start-lib are included in the link only when needed to resolve
undefined symbols. The -end-lib flag goes back to the normal behavior
of always including object files in the link. This mimics the
semantics of static libraries, but without needing to actually create
the archive file.

Reviewers: ruiu, smeenai, MaskRay

Reviewed By: ruiu, MaskRay

Subscribers: akhuang, llvm-commits

Tags: #llvm

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

llvm-svn: 370816
2019-09-03 20:32:16 +00:00
Vlad Tsyrklevich 802aab5de8 Revert "[lld-link] implement -start-lib and -end-lib"
This reverts commit r370487 as it is causing ASan/MSan failures on
sanitizer-x86_64-linux-fast

llvm-svn: 370550
2019-08-30 23:24:41 +00:00
Bob Haarman fd7569c8e3 [lld-link] implement -start-lib and -end-lib
Summary:
This implements -start-lib and -end-lib flags for lld-link, analogous
to the similarly named options in ld.lld. Object files after
-start-lib are included in the link only when needed to resolve
undefined symbols. The -end-lib flag goes back to the normal behavior
of always including object files in the link. This mimics the
semantics of static libraries, but without needing to actually create
the archive file.

Reviewers: ruiu, smeenai, MaskRay

Reviewed By: ruiu, MaskRay

Subscribers: akhuang, llvm-commits

Tags: #llvm

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

llvm-svn: 370487
2019-08-30 16:50:10 +00:00
Amy Huang a1c022c791 [COFF] Add libcall symbols to the link when LTO is being used
llvm-svn: 369694
2019-08-22 19:40:07 +00:00
Nico Weber 9c0716f116 ld.lld: Demangle symbols from archives in diagnostics
This ports r366573 from COFF to ELF.

There are now to toString(Archive::Symbol), one doing MSVC demangling
in COFF and one doing Itanium demangling in ELF, so rename these two
to toCOFFString() and to toELFString() to not get a duplicate symbol.

Nothing ever passes a raw Archive::Symbol to CHECK(), so these not
being part of the normal toString() machinery seems ok.

There are two code paths in the ELF linker that emits this type of
diagnostic:

1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test.

2. An additional one that's only used for libcalls if there's at least
   one bitcode in the link, and if the libcall symbol is lazy, and
   lazily loaded from an archive (i.e. not from a lazy .o file).
   (This code path was added in r339301.) Since all libcall names so far
   are C symbols and never mangled, the change there is not observable
   and hence not covered by tests.

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

llvm-svn: 366836
2019-07-23 19:00:01 +00:00
Nico Weber cb2c50028d lld-link: Demangle symbols from archives in diagnostics
Also add test coverage for thin archives (which are the only way I could
come up with to test at least some of the diagnostic changes).

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

llvm-svn: 366573
2019-07-19 13:29:10 +00:00
Rui Ueyama 136d27ab4d [Coding style change][lld] Rename variables for non-ELF ports
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
2019-07-11 05:40:30 +00:00
Rui Ueyama 7e296adec7 Make functions and member variables distinguishable even after the name style change. NFC.
llvm-svn: 365605
2019-07-10 09:10:01 +00:00
Reid Kleckner a30920c31f [COFF] Pack Name in Symbol as is done in ELF
Summary:
This assumes all symbols are <4GB long, so we can store them as a 32-bit
integer. This reorders the fields so the length appears first, packing
with the other bitfield data in the base Symbol object.

This saved 70MB / 3.60% of heap allocations when linking
browser_tests.exe with no PDB. It's not much as a percentage, but worth
doing. I didn't do performance measurements, I don't think it will be
measurable in time.

Reviewers: ruiu, inglorion, amccarth, aganea

Subscribers: llvm-commits

Tags: #llvm

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

llvm-svn: 358794
2019-04-19 22:51:49 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Nico Weber 1f3ab98aca lld-link: Spelling fixes in comments and minor style tweaks
Changes a few things I noticed while reading this code.
- fix a few typos in comments
- remove two `auto` uses where the type wasn't clear to me
- add comment saying that two sequential checks for `if (SparseChunks[SectionNumber] == PendingComdat)` are intentional
- name two parameters

No behavior change.

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

llvm-svn: 351101
2019-01-14 19:05:21 +00:00
Martin Storsjo 2bfa125fd6 [COFF] Allow automatic dllimport from gnu import libraries
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
2018-09-26 06:13:39 +00:00
Nico Weber c7bad5767b fix comment typo
llvm-svn: 340742
2018-08-27 14:22:25 +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
Martin Storsjo d9fd4a0de6 [COFF] Fix a comment about automatic resolving of dllimports from within a module. NFC.
Differential Revision: https://reviews.llvm.org/D50357

llvm-svn: 339100
2018-08-07 06:42:53 +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
Rui Ueyama 38781a59f6 Revert r325158: Convert an assert to a static_assert. NFC.
This reverts commit r325158 because it broke GCC builds.

llvm-svn: 325183
2018-02-14 22:43:43 +00:00
Sam Clegg ab31b7759d Convert an assert to a static_assert. NFC.
Differential Revision: https://reviews.llvm.org/D43305

llvm-svn: 325158
2018-02-14 19:28:46 +00:00
Sam Clegg 38f52b2eb8 Check that Symbol types are trivially destructible
This adds an extra level of static safety to our use of placement
new to allocate Symbol types.  It prevents the accidental addition
on a non-trivially-destructible member that could allocate and
leak memory.

From the spec: Storage occupied by trivially destructible objects
may be reused without calling the destructor.

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

llvm-svn: 325025
2018-02-13 17:32:31 +00:00
Rui Ueyama 2017d52b54 Move Memory.{h,cpp} to Common.
Differential Revision: https://reviews.llvm.org/D40571

llvm-svn: 319221
2017-11-28 20:39:17 +00:00
Peter Collingbourne 1621c20ffc Reland r319090, "COFF: Do not create SectionChunks for discarded comdat sections." with a fix for debug sections.
If /debug was not specified, readSection will return a null
pointer for debug sections. If the debug section is associative with
another section, we need to make sure that the section returned from
readSection is not a null pointer before adding it as an associative
section.

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

llvm-svn: 319133
2017-11-28 01:30:07 +00:00
Peter Collingbourne c8477b8234 Revert r319090, "COFF: Do not create SectionChunks for discarded comdat sections."
Caused test failures in check-cfi on Windows.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/20284

llvm-svn: 319100
2017-11-27 21:37:51 +00:00
Peter Collingbourne 3f2921f5ec COFF: Do not create SectionChunks for discarded comdat sections.
With this change, instead of creating a SectionChunk for each section
in the object file, we only create them when we encounter a prevailing
comdat section.

Also change how symbol resolution occurs between comdat symbols. Now
only the comdat leader participates in comdat resolution, and not any
other external associated symbols. This is more in line with how COFF
semantics are defined, and should allow for a more straightforward
implementation of non-ANY comdat types.

On my machine, this change reduces our runtime linking a release
build of chrome_child.dll with /nopdb from 5.65s to 4.54s (median of
50 runs).

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

llvm-svn: 319090
2017-11-27 20:42:34 +00:00
Peter Collingbourne f874bd67d8 COFF: Emit a COFF symbol table if /debug:dwarf is specified.
This effectively reverts r318548 and r318635 while keeping the
functionality behind the flag and preserving the bug fix from r318548.

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

llvm-svn: 318721
2017-11-21 01:14:14 +00:00
Peter Collingbourne 38e3a1ea17 COFF: Remove unused fields. NFC.
llvm-svn: 318635
2017-11-20 05:31:09 +00:00
Reid Kleckner 5883989e51 Remove a std::map and std::set that show up in LLD profiles
For GC roots, add a bit to SymbolBody to ensure that we don't add the
same root twice, and switch to a vector. In addition to being faster,
this may also fix some latent non-determinism. We iterate the GCRoot
list later and it the order should be deterministic.

For fixupExports, we can just use DenseMap. This is a simple string
uniquing task, and we don't iterate the map.

Reviewers: ruiu

Subscribers: llvm-commits

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

llvm-svn: 318072
2017-11-13 18:38:53 +00:00
Rui Ueyama f483da0038 Rename replaceBody -> replaceSymbol.
llvm-svn: 317383
2017-11-03 22:48:47 +00:00
Rui Ueyama f52496e1e0 Rename SymbolBody -> Symbol
Now that we have only SymbolBody as the symbol class. So, "SymbolBody"
is a bit strange name now. This is a mechanical change generated by

  perl -i -pe s/SymbolBody/Symbol/g $(git grep -l SymbolBody lld/ELF lld/COFF)

nd clang-format-diff.

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

llvm-svn: 317370
2017-11-03 21:21:47 +00:00
Rui Ueyama f78d097340 Remove a redundant union member.
This removes DefinedCOFF from SymbolUnion because DefinedCOFF is
not a leaf class. Pointed out by pcc.

llvm-svn: 317013
2017-10-31 17:07:47 +00:00
Rui Ueyama 616cd99194 [COFF] Merge Symbol and SymbolBody.
llvm-svn: 317007
2017-10-31 16:10:24 +00:00
Rui Ueyama 3f851704c1 Move new lld's code to Common subdirectory.
New lld's files are spread under lib subdirectory, and it isn't easy
to find which files are actually maintained. This patch moves maintained
files to Common subdirectory.

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

llvm-svn: 314719
2017-10-02 21:00:41 +00:00
Martin Storsjo d2752aa9ec [COFF] Add support for aligncomm directives
These are emitted for comm symbols in object files, when targeting
a GNU environment.

Alternatively, just ignore them since we already align CommonChunk
to the natural size of the content (up to 32 bytes). That would only
trade away the possibility to overalign small symbols, which doesn't
sound like something that might not need to be handled?

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

llvm-svn: 310871
2017-08-14 19:07:27 +00:00
Reid Kleckner eacdf04fdd [PDB] Write public symbol records and the publics hash table
Summary:
MSVC link.exe records all external symbol names in the publics stream.
It provides similar functionality to an ELF .symtab.

Reviewers: zturner, ruiu

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 309303
2017-07-27 18:25:59 +00:00
Rui Ueyama e1b48e099c Rename ObjectFile ObjFile for COFF as well.
llvm-svn: 309228
2017-07-26 23:05:24 +00:00
Reid Kleckner a1001b8f38 [COFF] Allow debug info to relocate against discarded symbols
Summary:
In order to do this without switching on the symbol kind multiple times,
I created Defined::getChunkAndOffset and use that instead of
SymbolBody::getRVA in the inner relocation loop.

Now we get the symbol's chunk before switching over relocation types, so
we can test if it has been discarded outside the inner relocation type
switch. This also simplifies application of section relative
relocations. Previously we would switch on symbol kind to compute the
RVA, then the relocation type, and then the symbol kind again to get the
output section so we could subtract that from the symbol RVA. Now we
*always* have an OutputSection, so applying SECREL and SECTION
relocations isn't as much of a special case.

I'm still not quite happy with the cleanliness of this code. I'm not
sure what offsets and bases we should be using during the relocation
processing loop: VA, RVA, or OutputSectionOffset.

Reviewers: ruiu, pcc

Reviewed By: ruiu

Subscribers: majnemer, inglorion, llvm-commits, aprantl

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

llvm-svn: 306566
2017-06-28 17:06:35 +00:00
Reid Kleckner eb8c0f9d51 [COFF] Fix SECREL and SECTION relocations against common symbols
Summary:
They do the obvious thing: provide the section index of .bss and the
offset of the symbol in .bss.

Reviewers: ruiu

Subscribers: llvm-commits

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

llvm-svn: 306304
2017-06-26 16:45:36 +00:00
Reid Kleckner 502d4ce2e4 [COFF] Improve synthetic symbol handling
Summary:
The main change is that we can have SECREL and SECTION relocations
against ___safe_se_handler_table, which is important for handling the
debug info in the MSVCRT.

Previously we were using DefinedRelative for __safe_se_handler_table and
__ImageBase, and after we implement CFGuard, we plan to extend it to
handle __guard_fids_table, __guard_longjmp_table, and more.  However,
DefinedRelative is really only suitable for implementing __ImageBase,
because it lacks a Chunk, which you need in order to figure out the
output section index and output section offset when resolving SECREl and
SECTION relocations.

This change renames DefinedRelative to DefinedSynthetic and gives it a
Chunk. One wart is that __ImageBase doesn't have a chunk. It points to
the PE header, effectively. We could split DefinedRelative and
DefinedSynthetic if we think that's cleaner and creates fewer special
cases.

I also added safeseh.s, which checks that we don't emit a safe seh table
entries pointing to garbage collected handlers and that we don't emit a
table at all when there are no handlers.

Reviewers: ruiu

Reviewed By: ruiu

Subscribers: inglorion, pcc, llvm-commits, aprantl

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

llvm-svn: 306293
2017-06-26 15:39:52 +00:00
Reid Kleckner 8456411e3b [COFF] Fix SECTION and SECREL relocation handling for absolute symbols
Summary:
For SECTION relocations against absolute symbols, MSVC emits the largest
output section index plus one. I've implemented that by threading a
global variable through DefinedAbsolute that is filled in by the Writer.
A more library-oriented approach would be to thread the Writer through
Chunk::writeTo and SectionChunk::applyRel*, but Rui seems to prefer
doing it this way.

MSVC rejects SECREL relocations against absolute symbols, but only when
the relocation is in a real output section. When the relocation is in a
CodeView debug info section destined for the PDB, it seems that this
relocation error is suppressed, and absolute symbols become zeros in the
object file. This is easily implemented by checking the input section
from which we're applying relocations.

This should fix errors about __safe_se_handler_table and
__guard_fids_table when linking the CRT and generating a PDB.

Reviewers: ruiu

Subscribers: aprantl, llvm-commits

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

llvm-svn: 306071
2017-06-22 23:33:04 +00:00
Rui Ueyama 9aa82f76ac Garbage collect dllimported symbols.
This is a different implementation than r303225 (which was reverted
in r303270, re-submitted in r303304 and then re-reverted in r303527).

In the previous patch, I tried to add Live bit to each dllimported
symbol. It turned out that it didn't work with "oldnames.lib" which
contains a lot of weak aliases to dllimported symbols.

The way we handle weak aliases is to check if undefined symbols
can be resolved using weak aliases, and if so, memcpy the Defined
symbols to weak Undefined symbols, so that any references to weak
aliases automatically see defined symbols instead of undefined ones.

This memcpy happens before MarkLive kicks in.

That means we may have multiple copies of dllimported symbols. So
turning on one instance's Live bit is not enough.

This patch moves the Live bit to dllimport file. Since multiple
copies of dllsymbols still point to the same file, we can use it as the
central repository to keep track of liveness.

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

llvm-svn: 303814
2017-05-24 22:30:06 +00:00