In mingw environments, resources are normally compiled to resource
object files directly, instead of letting the linker convert them to
COFF format.
Since some time, GCC supports the notion of a default manifest object.
When invoking the linker, GCC looks for the default manifest object
file, and if found in the expected path, it is added to linker commands.
The default manifest is one that indicates support for the latest known
versions of windows, to implicitly unlock the modern behaviours of certain
APIs.
Not all mingw/gcc distributions include this file, but e.g. in msys2,
the default manifest object is distributed in a separate package (which
can be but might not always be installed).
This means that even if user projects only use one single resource
object file, the linker can end up with two resource object files,
and thus needs to support merging them.
The default manifest has a language id of zero, and GNU ld has got
logic for dropping a manifest with a zero language id, if there's
another manifest present with a nonzero language id. If there are
multiple manifests with a nonzero language id, the merging process
errors out.
Differential Revision: https://reviews.llvm.org/D66825
llvm-svn: 370974
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
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
Extend WindowsResourceParser to support using a ResourceSectionRef for
loading resources from an object file.
Only allow merging resource object files in mingw mode; keep the
existing error on multiple resource objects in link mode.
If there only is one resource object file and no .res resources,
don't parse and recreate the .rsrc section, but just link it in without
inspecting it. This allows users to produce any .rsrc section (outside
of what the parser supports), just like before. (I don't have a specific
need for this, but it reduces the risk of this new feature.)
Separate out the .rsrc section chunks in InputFiles.cpp, and only include
them in the list of section chunks to link if we've determined that there
only was one single resource object. (We need to keep other chunks from
those object files, as they can legitimately contain other sections as
well, in addition to .rsrc section chunks.)
Differential Revision: https://reviews.llvm.org/D66824
llvm-svn: 370436
This avoids a spurious and confusing log message in cases where
both e.g. "alias" and "__imp_alias" exist.
Differential Revision: https://reviews.llvm.org/D65598
llvm-svn: 367673
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
This reverts r365990 (git commit 1a6053ebc6)
The test no longer depends on the Visual C++ libraries. I confirmed that
the crash still reproduces with the new test case if I remove the null
check.
llvm-svn: 366095
Summary:
This implements -thinlto-index-only, -thinlto-index-only:,
and -thinlto-emit-imports-files options in lld-link. They are
analogous to their counterparts in ld.lld: -thinlto-index-only
causes us to perform ThinLTO's thin link and write index files,
but not perform code generation. -thinlto-index-only: does the
same, but also writes a text file listing the native object
files expected to be generated. -thinlto-emit-imports-files
creates a text file next to each index file, listing the files
to import from.
Reviewers: ruiu, tejohnson, pcc, rnk
Subscribers: mehdi_amini, steven_wu, dexonsmith, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64461
llvm-svn: 365800
GNU windres, and MS cvtres (unless the /readonly option is passed)
produce read-write .rsrc sections, when creating resource object files.
This caused the sections to not be added to the precreated RsrcSec,
and therefore not be added to the data directory.
Differential Revision: https://reviews.llvm.org/D63837
llvm-svn: 364660
PDBs may not necessarily contain an IPI stream. Handle this case
gracefully.
The test case was verified to work with MS link.exe.
Patch by Vladimir Panteleev, with a small simplification
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D63178
llvm-svn: 363213
Summary: Deduplicate S_CONSTANTS when linking, if they have the same value.
Reviewers: rnk
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63151
llvm-svn: 363089
The age field is only there to say how many times an OBJ or a PDB was incrementally linked. It shouldn't be used to validate the link between the OBJ and the PDB.
Differential Revision: https://reviews.llvm.org/D62837
llvm-svn: 362572
We need to have all input files ready before doing debuginfo type merging.
This patch is moving the late PDB type server discovery much earlier in the process, when the explicit inputs (OBJs, LIBs) are loaded.
The short term goal is to parallelize type merging.
Differential Revision: https://reviews.llvm.org/D60095
llvm-svn: 362393
We need to have all input files ready before doing debuginfo type merging.
This patch is moving the late PDB type server discovery much earlier in the process, when the explicit inputs (OBJs, LIBs) are loaded.
The short term goal is to parallelize type merging.
Differential Revision: https://reviews.llvm.org/D60095
llvm-svn: 361842
These yaml test cases appear to have been affected by PR41836
Right now what happens is that these empty .bss sections are merged into
.data, then the .data output section ends up having a zero virtual size,
and it is discarded from the output after addresses are assigned.
However, we've already assigned OutputSections to Chunks, so we don't
correctly report the zero-sized chunks that were in there as having been
discarded. Soon, we will report them as discarded, so these test cases
need to be updated to have a non-zero size so they aren't discarded.
llvm-svn: 360476
As a side benefit, lld-link now reports more than one duplicate resource
entry before exiting with an error even if the new flag is not passed.
llvm-svn: 359829
When faced with command line options such as "crtbegin.o appmain.o
-lsomelib crtend.o", GNU ld pulls in all necessary object files from
somelib before proceeding to crtend.o.
LLD operates differently, only loading object files from any
referenced static libraries after processing all input object files.
This uses a similar hack as in the ELF linker. Here, it moves crtend.o
to the end of the vector of object files. This makes sure that
terminator chunks for sections such as .eh_frame gets ordered last,
fixing DWARF exception handling for libgcc and gcc's crtend.o.
Differential Revision: https://reviews.llvm.org/D60628
llvm-svn: 358394
Summary:
Take the Index into account in `getDelayImportTable`, otherwise we
always return the entry for the first delay DLL reference.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60081
llvm-svn: 357697
When mismatched #pragma detect_mismatch declarations occur, now print the conflicting OBJs.
lld-link: error: /failifmismatch: mismatch detected for 'TEST':
>>> test.obj has value 1
>>> test2.obj has value 2
Fixes PR38579
Differential Revision: https://reviews.llvm.org/D58910
llvm-svn: 355543
This change allows for link-time merging of debugging information from
Microsoft precompiled types OBJs compiled with cl.exe /Z7 /Yc and /Yu.
This fixes llvm.org/PR34278
Differential Revision: https://reviews.llvm.org/D45213
llvm-svn: 346154
For certain cases of inline functions written to comdat sections,
GCC 5.x produces a weak symbol in addition, which would end up
undefined in some cases.
This no longer seems to happen with GCC 6.x or newer though.
Differential Revision: https://reviews.llvm.org/D52602
llvm-svn: 343877
(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
When GNU tools create a weak alias, they produce a strong symbol
named .weak.<weaksymbol>.<relatedstrongsymbol>.
GNU ld allows many such weak alternatives for the same weak symbol, and
the linker picks the first one encountered.
This can't be reproduced by assembling from .s files, since llvm-mc
produces symbols named .weak.<weaksymbol>.default in these cases.
Differential Revision: https://reviews.llvm.org/D52601
llvm-svn: 343704
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
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
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
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
- Log the reason for a PDB or precompiled-OBJ load failure
- Properly handle out-of-date PDB or precompiled-OBJ signature by displaying a corresponding error
- Slightly change behavior on PDB failure: any subsequent load attempt from another OBJ would result in the same error message being logged
- Slightly change behavior on PDB failure: retry with filename only if previous error was ENOENT ("no such file or directory")
- Tests: a. for native PDB errors; b. cover all the cases above
Differential Revision: https://reviews.llvm.org/D51559
llvm-svn: 341825
MinGW configurations don't use associative comdats, as GNU ld doesn't
support that. Instead they produce normal comdats named .text$sym,
.xdata$sym and .pdata$sym.
GNU ld doesn't discard any comdats starting with .xdata or .pdata,
even if --gc-sections is used (while it does discard other unreferenced
comdats), regardless of what symbol name is used after the $ separator.
For LLD, treat any such comdat as implicitly associative to the base
symbol. This requires maintaining a map from symbol name to section
number, but that is only maintained when the MinGW flag has been
enabled.
Differential Revision: https://reviews.llvm.org/D49700
llvm-svn: 339058
It's not an error if a common symbol (uninitialized data, with alignment
specified via the aligncomm directive) is replaced with a regular
one with initialized data (with alignment specified via the section
chunk).
Differential Revision: https://reviews.llvm.org/D50268
llvm-svn: 339049
This patch changes relative path for source files in obj files to
absolute path in PDB when linking with added flag.
I will make obj file generated by clang-cl independent from build
directory for chromium build. But I don't want to confuse visual studio
debugger or require additional configuration. To attain this goal, I
added flag to convert relative source file path in obj to absolute path
when emitting PDB.
By removing absolute path from obj files, we can share build cache
between chromium developers even when they are doing debug build.
That will make build time faster.
More context:
https://bugs.chromium.org/p/chromium/issues/detail?id=712796https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/5HXSVX-7fPc
llvm-svn: 337439
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
The reference implementation uses a case-insensitive string
comparison for strings of equal length. This will cause the
string "tEo" to compare less than "VUo". However we were using
a case sensitive comparison, which would generate the opposite
outcome. Switch to a case insensitive comparison. Also, when
one of the strings contains non-ascii characters, fallback to
a straight memcmp.
The only way to really test this is with a DIA test. Before this
patch, the test will fail (but succeed if link.exe is used instead
of lld-link). After the patch, it succeeds even with lld-link.
llvm-svn: 336464
It seems like the debugger first computes a symbol's bucket,
and then does a binary search of entries in the bucket using the
symbol's name in order to find it. If the bucket entries are not
in sorted order, this obviously won't work. After this patch a
couple of simple test cases show that we generate an exactly
identical GSI hash stream, which is very nice.
llvm-svn: 336405
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
Martin Storsjo