Natvis is a debug language supported by Visual Studio for
specifying custom visualizers. The /NATVIS option is an
undocumented link.exe flag which will take a .natvis file
and "inject" it into the PDB. This way, you can ship the
debug visualizers for a program along with the PDB, which
is very useful for postmortem debugging.
This is implemented by adding a new "named stream" to the
PDB with a special name of /src/files/<natvis file name>
and simply copying the contents of the xml into this file.
Additionally, we need to emit a single stream named
/src/headerblock which contains a hash table of embedded
files to records describing them.
This patch adds this functionality, including the /NATVIS
option to lld-link.
Differential Revision: https://reviews.llvm.org/D44328
llvm-svn: 327895
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
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
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
GNU ld has got a number of different flags for adjusting how to
behave around stdcall functions. The --kill-at flag strips the
trailing sdcall suffix from exported functions (which otherwise
is included by default in MinGW setups).
This also strips it from the corresponding import library though.
That makes it hard to link to such an import library from code
that calls the functions - but this matches what GNU ld does with
this flag. Therefore, this flag is probably not sensibly used
together with import libraries, but probably mostly when creating
some sort of plugin, or if creating the import library separately
with dlltool.
Differential Revision: https://reviews.llvm.org/D44292
llvm-svn: 327561
This makes the output of some flag names in warning messages consistent with
the output of /? and the output of flags in most other diagnostics.
https://reviews.llvm.org/D44307
llvm-svn: 327261
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
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
For now this is NFC, but this small refactor opens the door to
letting us embed a hash of the PDB in the build id field of the
PDB.
Differential Revision: https://reviews.llvm.org/D43913
llvm-svn: 326453
When merging in types from a type server PDB, we would use a
pointer into the type server PDB's mapped file buffer directly
to avoid copying data. However, we would close the type server
PDB after we finished merging in its types, which would unmap
all of its memory. This would lead to a use after free.
We fix this by making a strong reference in the PDBLinker class
to all referenced type server PDBs, thereby making it safe to
hold pointers into its memory mapped contents.
This fixes llvm.org/pr36455
Differential Revision: https://reviews.llvm.org/D43834
llvm-svn: 326345
This should resolve the issue that lld build fails in some hosts
that uses case-insensitive file system.
Differential Revision: https://reviews.llvm.org/D43788
llvm-svn: 326339
Previously wasm used a separate header to declare markLive
and ELF used to declare ICF. This change makes each backend
consistently declare these in their own headers.
Differential Revision: https://reviews.llvm.org/D43529
llvm-svn: 325631
The profailing style in lld seem to be to not include such empty lines.
Clang-tidy/clang-format seem to handle this just fine.
Differential Revision: https://reviews.llvm.org/D43528
llvm-svn: 325629
Summary:
With D43396, no clients use the Path parameter anymore.
This is the lld side fix with D43400.
Depends on D43396 and D43400.
Reviewers: pcc
Subscribers: emaste, inglorion, arichardson, llvm-commits
Differential Revision: https://reviews.llvm.org/D43401
llvm-svn: 325620
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
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
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
Summary:
r323164 made lld-link not overwrite import libraries when their
contents haven't changed. MSVC's link.exe does this only when
performing incremental linking. This change makes lld-link's import
library overwriting similarly dependent on whether or not incremental
linking is being performed. This is controlled by the /incremental or
/incremental:no options. In addition, /opt:icf, /opt:ref, and /order
turn off /incremental and issue a warning if /incremental was
specified on the command line.
Reviewers: rnk, ruiu, zturner
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42716
llvm-svn: 323930
Summary: Instead of fatal-ing out when missing a type server PDB, insead warn and cache the miss.
Reviewers: rnk, zturner
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42188
llvm-svn: 323893
I didn't implement the feature in the original patch because I didn't
come up with an idea to do that easily and efficiently. Turned out that
that is actually easy to implement.
In this patch, we collect comdat sections before gc is run and warn on
nonexistent symbols in an order file.
Differential Revision: https://reviews.llvm.org/D42658
llvm-svn: 323699
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
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
Summary:
This detects when an import library is about to be overwritten with a
newly built one with the same contents, and keeps the old library
instead. The use case for this is to avoid needlessly rebuilding
targets that depend on the import library in build systems that rely
on timestamps to determine whether a target requires rebuilding.
This feature was requested in PR35917.
Reviewers: rnk, ruiu, zturner, pcc
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D42326
llvm-svn: 323164
There's some abstraction overhead in the underlying
mechanisms that were being used, and it was leading to an
abundance of small but not-free copies being made. This
showed up on a profile. Eliminating this and going back to
a low-level byte-based implementation speeds up lld with
/DEBUG between 10 and 15%.
Differential Revision: https://reviews.llvm.org/D42148
llvm-svn: 322871
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
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
The compiler could not find the conversion from
unique_ptr<WritableMemoryBuffer> to unique_ptr<MemoryBuffer>. This will
hopefully help it along.
llvm-svn: 322365
Patch by Takuto Ikuta.
This patch reduces lld link time of chromium's blink_core.dll in
component build.
Total size of input argument in .directives become nearly 300MB in the
build and almost all its content are /EXPORT.
To reduce time of parsing too many /EXPORT option in the build, I
introduce fastpath for /EXPORT in ArgParser::parseDirectives.
On my desktop machine, 4 times stats of the link time are like below.
Improved around 20%.
This patch
TotalSeconds : 8.6217627
TotalSeconds : 8.5402175
TotalSeconds : 8.6855853
TotalSeconds : 8.3624441
Ave : 8.5525024
master
TotalSeconds : 10.9975031
TotalSeconds : 11.3409428
TotalSeconds : 10.6332897
TotalSeconds : 10.7650687
Ave : 10.934201075
llvm-svn: 322117
It was being set but never used, and its value is only ever needed
locally in lld::coff::link.
Differential Revision: https://reviews.llvm.org/D41814
llvm-svn: 322026
Previously, the COFF driver would call exit(1) from the
ErrorHandler in the case of a link error, even if
CanExitEarly=false was specified. Now it initializes
the ErrorHandler in the same way that the ELF driver does.
Patch by Andrew Kelley.
Differential Revision: https://reviews.llvm.org/D41803
llvm-svn: 321983
This is not a record type that clang currently generates,
but it is a record that is encountered in object files generated
by cl. This record is unusual in that it refers directly to
the string table instead of indirectly to the string table via
the FileChecksums table. Because of this, it was previously
overlooked and we weren't remapping the string indices at all.
This would lead to crashes in MSVC when trying to display a
variable whose debug info involved an S_FILESTATIC.
Original bug report by Alexander Ganea
Differential Revision: https://reviews.llvm.org/D41718
llvm-svn: 321883
Summary:
lld-link accepts link.exe's /ignore option, but used to ignore
it. This can lead to semantic differences when warnings are treated as
fatal errors. One such case is when we resolve an __imp_ symbol to a
local definition. We emit a warning in that case, which /wx turns into
a fatal. This change makes lld-link accept /ignore:4217 to suppress
that warning, so that code that links with link.exe /wx /ignore:4217
links with lld-link, too.
Fixes PR35762.
Reviewers: rnk, ruiu
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41606
llvm-svn: 321512
Patch by Takuto Ikuta.
This patch reduces link time of chromium's blink_core.dll in component
build. Total size of input argument in .directives become nearly 300MB
in the build and no rsp file is used. Speedup link by skipping duplicate
parsing.
On my desktop machine, 4 times stats are like below. Improved around 15%.
This patch
TotalSeconds : 18.408538
TotalSeconds : 17.2996744
TotalSeconds : 17.1053862
TotalSeconds : 17.809777
avg: 17.6558439
master
TotalSeconds : 20.9290504
TotalSeconds : 19.9158213
TotalSeconds : 21.0643515
TotalSeconds : 20.8775831
avg: 20.696701575
Differential Revision: https://reviews.llvm.org/D41581
llvm-svn: 321470
/debug and /debug:dwarf are orthogonal. An object file can contain both
CodeView and DWARF debug info, so the combination of /debug:dwarf and
/debug should generate both DWARF and a PDB, rather than /debug:dwarf
always suppressing PDB creation.
/nopdb is now redundant and can be removed. /debug /nopdb was previously
used to support DWARF, but specifying /debug:dwarf is entirely
equivalent to that combination now.
Differential Revision: https://reviews.llvm.org/D41310
llvm-svn: 320896
We can just pass multiple options to hasArgs (which will check for any
of those options being present) instead of calling it multiple times.
llvm-svn: 320892
Locally imported symbols are a very surprising linker feature. link.exe
warns for them, and we should warn too.
Differential Revision: https://reviews.llvm.org/D41269
llvm-svn: 320792
This adds the /DEBUG:GHASH option to LLD which will look for
the existence of .debug$H sections in linker inputs and use them
to accelerate type merging. The clang-cl side has already been
added, so this completes the work necessary to begin experimenting
with this feature.
Differential Revision: https://reviews.llvm.org/D40980
llvm-svn: 320719
This is similar to what was added in SVN r277838 for 24 bit
branch instructions.
Differential Revision: https://reviews.llvm.org/D41163
llvm-svn: 320677
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
In the following command line,
lld-link foo/bar.lib /defaultlib:bar.lib
"/defaultlib:bar.lib" should be a nop even if a file with the same
name exists in other library search path.
Fixes https://bugs.llvm.org/show_bug.cgi?id=35476
Differential Revision: https://reviews.llvm.org/D41094
llvm-svn: 320434
It's pretty annoying to have LLD lowercase paths in error messages when
cross-compiling from a case-sensitive filesystem, since e.g. if I want
to examine the problematic object file, I have to perform some manual
case correction instead of just being able to copy the path from the
error message.
Differential Revision: https://reviews.llvm.org/D40931
llvm-svn: 319996
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
Adds support for "/ENTRY" and "/SUBSYSTEM" linker options in .drectve
sections. Some Mozilla binaries were using these directives and MSVC
link.exe appears to allow them. No attempt is made to reconcile these
with the options on the command line.
Patch by David Major!
Differential Revision: https://reviews.llvm.org/D39972
llvm-svn: 319356
A couple of places in LLD were passing references to
TypeTableCollections around, which makes it hard to change the
implementation at runtime. However, these cases only needed to
iterate over the types in the collection, and TypeCollection
already provides a handy abstract interface for this purpose.
By implementing this interface, we can get rid of the need to
pass TypeTableBuilder references around, which should allow us
to swap the implementation at runtime in subsequent patches.
llvm-svn: 319345
GNU ld has got an exception for such symbols, and mingw-w64
occasionally uses that exception to avoid exporting symbols in cases
where they otherwise aren't caught by the other exclusion mechanisms.
Differential Revision: https://reviews.llvm.org/D40553
llvm-svn: 319291
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
This allows grouping all sections like ".ctors.12345" into ".ctors".
For MinGW, the numerical values for such ctors are all zero-padded,
so a lexical sort is good enough.
Differential Revision: https://reviews.llvm.org/D40408
llvm-svn: 319151
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
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
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
Summary: MSVC does this. The user can override it with their own /merge: flag.
Reviewers: ruiu, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40197
llvm-svn: 318699
Don't crash if we encounter a reference to an early discarded section
(such as .drectve). Instead, handle them the same way as sections
discarded by comdat merging, i.e. either print an error message or
(for debug sections) silently ignore the relocation.
Differential Revision: https://reviews.llvm.org/D40235
llvm-svn: 318689
This requirement was added in r254578 to fix pr25686. However, it
appears to have originated from a misdiagnosis of the problem: link.exe
refused to merge the two sections because they are non-executable,
not because they have internal leaders. If I set up a similar scenario
with functions instead of globals I see that link.exe merges them.
Differential Revision: https://reviews.llvm.org/D40236
llvm-svn: 318682
Now that our support for PDB emission is reasonably good, there is
no longer a need to emit a COFF symbol table.
Also fix a bug where we would fail to emit a string table for long
section names if /debug was not specified.
Differential Revision: https://reviews.llvm.org/D40189
llvm-svn: 318548
Summary:
Many small functions have identical unwind info because they push the
same sets of CSRs in the same order and have the same stack and prologue
size. The VC linker merges duplicate .xdata, and so should LLD.
This reduces the .xdata section size of clang.exe from 1.8MB to 94KB.
Reviewers: pcc, ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40160
llvm-svn: 318547
Sections that will be mapped at runtime will only have the short
section name available, since the string table it points into isn't
mapped. Therefore prefer truncating those names over writing a
long name that is unavailable at runtime.
This allows libunwind to find the .eh_frame section at runtime even
if the module was built with debug info enabled.
Differential Revision: https://reviews.llvm.org/D40025
llvm-svn: 318391
If -opt:noref is specified, they can end up with isLive() == 1
when the autoexport check is run.
To reduce the risk of potential issues, only consider exporting
DefinedRegular and DefinedCommon, nothing else.
Differential Revision: https://reviews.llvm.org/D40014
llvm-svn: 318384
Summary:
We previously assumed that all SafeSEH handlers are
DefinedRegular symbols. This is not the case for handlers defined in
DLLs. As a result, we were failing to emit entries in the SafeSEH
table for those handlers. This change fixes that.
Fixes PR35324.
Reviewers: rnk, ruiu
Reviewed By: rnk
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D40102
llvm-svn: 318364
Even if we don't actually write any string table contents, the
4 byte size for the string table will always be written. Make
sure we accommodate for this in the file size. Since this size
is aligned up, this would seldom be an issue in practice.
Differential Revision: https://reviews.llvm.org/D39891
llvm-svn: 318284
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
ICF and GC impair debugging, so MSVC disables these optimizations when
/debug is passed. They are still on by default when no PDB is produced.
This change also makes /opt:ref enable ICF, which is consistent with
MSVC: https://msdn.microsoft.com/en-us/library/bxwfs976.aspx
We should consider making /opt:icf fold readonly data in the near
future. LLD used to do this, but we disabled it because it breaks too
many programs. MSVC only does this if the user explicitly passes
/opt:icf.
Reviewers: ruiu, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D39885
llvm-svn: 318071
I never ran into this until lld-link started enabling debug output
by default for the mingw mode. I haven't been able to verify that
this actually behaves correctly, but this relocation is handled
identically on all other architectures so far.
Differential Revision: https://reviews.llvm.org/D39754
llvm-svn: 317669
Summary:
__safe_se_handler_base should be either absolute 0 (when no SafeSEH
table is present), or relative to the image base (when the table is
present). An earlier change inadvertedly made the symbol absolute in
both cases, leading to the SafeSEH table not being locatble at run
time. This change fixes that and updates the safeseh test to check for
the presence of the relocation.
Reviewers: rnk, ruiu
Reviewed By: ruiu
Subscribers: ruiu, llvm-commits
Differential Revision: https://reviews.llvm.org/D39765
llvm-svn: 317635
These libraries contain a number of object files with compat wrappers,
in addition to the normal import library entries.
Differential Revision: https://reviews.llvm.org/D39684
llvm-svn: 317505
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
This patch resurrects code that was removed in r317007 to not access
beyond allocated memory for a symbol.
Differential Revision: https://reviews.llvm.org/D39458
llvm-svn: 317039
IIUC, SizeOfImage is the distance from the end of the last section to
the image base, rounded up to the page size. So the previous code is
wrong.
Should fix https://bugs.llvm.org/show_bug.cgi?id=34949
(It is nice to know that lld is already being used to create Putty
distribution binaries.)
llvm-svn: 316626
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D39259
llvm-svn: 316624
If /manifest:embed is enabled we're already creating a resource file
out of these flags and adding it to the linkrepro, and it doesn't
seem worth being able to repro side-by-side manifests.
Includes a test that covers this commit as well as r315948.
Differential Revision: https://reviews.llvm.org/D38975
llvm-svn: 316547
link.exe supports this option to convert warnings into errors, and it's
useful to support in LLD as well.
Differential Revision: https://reviews.llvm.org/D39148
llvm-svn: 316502
LLD's handling of boolean flags is suboptimal:
* All boolean flags have a corresponding `:no` flag to turn the flag
off, and the linker should scan for both the non-suffixed and suffixed
flags (and the last one should win), but right now it only scans for
either the suffixed or non-suffixed flag (depending on the default
flag value).
* The `B` multiclass only allows specifying help text for the suffixed
(`:no`) flag, but for some flags (e.g. `/appcontainer`) the help text
should be associated with the non-suffixed flag instead.
Extend the `B` multiclass to have help text for both non-suffixed and
suffixed flag variants, and alter the existing help text accordingly in
some cases. Scan for both the non-suffixed and suffixed variants in the
driver and set config values accordingly.
This should mostly have no behavior change, apart from the added help
text and the modified argument scanning. Some flags are handled slightly
differently now, however; for example, LLD would previously always treat
64-bit images as large address aware, whereas `/largeaddressaware:no` is
now respected for 64-bit images (which is also how link.exe behaves).
Differential Revision: https://reviews.llvm.org/D39216
llvm-svn: 316501
The type index is from the TPI stream, not the IPI stream. Fix the
dumper, fix type index discovery, and add a test in LLD.
Also improve the log message we emit when we fail to rewrite type
indices in LLD. That's how I found this bug.
llvm-svn: 316461
Previously, the COFF driver would call exit(0) when called
as a library. Now it takes `ExitEarly` option, and if it
is false, it doesn't exit. So it is now more library-friendly.
Furthermore, link() calls freeArena() before returning, to
clean up resources.
Based on an Andrew Kelley's patch.
Differential Revision: https://reviews.llvm.org/D39202
llvm-svn: 316370
This fixes exporting functions in the following cases:
- functions starting with an underscore in def files
- functions starting with an underscore, via dllexport attributes, for mingw
- fastcall and vectorcall functions when declared undecorated in def files
- vectorcall functions when declared decorated in def files
- stdcall functions when declared decorated in def files for mingw
This still exports the stdcall functions with the wrong name
in the normal msvc/link.exe mode, if declared with decoration in
the def file though (this is not a regression though). Exporting
functions via def files including decoration is not something I
believe is routinely done though, but is tested to try to match
link.exe's behaviour as far as easily possible.
Differential Revision: https://reviews.llvm.org/D39170
llvm-svn: 316317
This should fix the build after SVN r316178, which worked fine
on GCC 5.4, but failed on clang with errors like these:
MinGW.h:26:3: error: too few template arguments for class template 'StringSet'
StringSet<> ExcludeSymbols;
^
lld/Common/LLVM.h:28:30: note: template is declared here
template<typename T> class StringSet;
Don't forward declare and add the using directive in the main
lld/Common/LLVM.h header, but just qualify the class name
in MinGW.h instead.
llvm-svn: 316180
Now that we have our own implementation of cvtres, we can add resource
files directly to the linkrepro.
Differential Revision: https://reviews.llvm.org/D38974
llvm-svn: 315954
Without this, /linkrepro would create an invalid tar file.
No tests because this requires Windows and the linkrepro tests
require not-Windows.
Differential Revision: https://reviews.llvm.org/D38973
llvm-svn: 315948
GNU ld automatically exports all symbols if no symbols have
been chosen to export via either def files or dllexport attributes.
The same behaviour can also be enabled via the GNU ld option
--export-all-symbols, in case some symbols are marked for export
via a def file or dllexport attribute.
The list of excluded symbols is from GNU ld, minus the
cygwin specific symbols.
Also add support for outputting the actual list of exported
symbols in a def file, as in the GNU ld option --output-def.
These options in GNU ld are documented in
https://sourceware.org/binutils/docs/ld/WIN32.html.
This currently exports all symbols from object files pulled in
from libmingw32 and libmingwex and other static libraries
that are linked in.
Differential Revision: https://reviews.llvm.org/D38760
llvm-svn: 315562
This is implemented in the same way as the other ADDR32NB relocations
for ARM and X64.
Differential Revision: https://reviews.llvm.org/D38815
llvm-svn: 315561
Fixes PR34306.
This is because it usually results in more compact code, and because
there are also known code generation bugs when using the PIC model
(see bug).
Based on a patch by Carlo Kok.
Differential Revision: https://reviews.llvm.org/D38769
llvm-svn: 315400
I believe the reason why we used warn() instead of error() to report
undefined symbols is because the older implementation of error() exitted
immediately. Here, we want to find as many undefined symbols as we can,
so I chose to use warn() instead of error().
Now error() does not exit immediately, so it doesn't make sense to keep
them as warnings.
Differential Revision: https://reviews.llvm.org/D38652
llvm-svn: 315131
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
Computing section content hashes early seems like a win in terms of
performance. It increases a chance that two different sections will get
different class IDs from the beginning.
Without threads, this patch improves Chromium link time by about 0.3
seconds. With threads, by 0.1 seconds. That's less than 1% time saving
but not bad for a small patch.
llvm-svn: 314644
According to Microsoft's PE/COFF documentation, a SECREL relocation is
"The 32-bit offset of the target from the beginning of its section". By
my reading, the "from the beginning of its section" implies that the
offset is unsigned.
Change from an assertion to an error, since it's possible to trigger
this condition normally for input files with very large sections, and we
should fail gracefully for those instead of asserting.
Differential Revision: https://reviews.llvm.org/D38020
llvm-svn: 313703
Sections are limited to 4 GiB. Error out early if a section exceeds this
size, rather than overflowing the section size and getting confusing
assertion failures/segfaults later.
Differential Revision: https://reviews.llvm.org/D38005
llvm-svn: 313699
r303378 was submitted because r303374 (Merge IAT and ILT) made lld's
output incompatible with the Binding feature. Now that r303374 was
reverted, we do not need to keep this change.
Pointed out by pcc.
llvm-svn: 313414
Arg instances can be claimed. After claimed, its `isClaimed` function
returns true. We do not use that notion in lld, so using NoClaim
versions of functions is just confusing. This patch is to just use
hasArg instead of hasArgNoClaim.
llvm-svn: 313187
In MinGW configurations (GCC, or clang with a *-windows-gnu target),
the -export directives in the object file contains the undecorated
symbol name, while it is decorated in MSVC configurations. (On the
command line, link.exe takes an undecorated symbol name for the
-export argument though.)
Differential Revision: https://reviews.llvm.org/D37772
llvm-svn: 313174
/natvis is a new command line option introduced by MSVC 2017.
We eventually have to support it, but for now, let's ignore it so that
we can at least link stuff instead of printing out an error.
Patch by Michael Rickert.
llvm-svn: 312966
Summary:
Previous would throw warning whenever libxml2 is not installed. Now
only give this warning if merging manifest fails.
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37240
llvm-svn: 312604
Looks like raw_string_ostream is buffered. If we do not call `flush`
nor `str`, it is not guaranteed that a result string has all characters
that were written to it.
It wasn't failing on buildbots, but I could reproduce the issue on my
Windows workstation.
llvm-svn: 312577
Apply the simplification suggestions that Peter Collingbourne made
during the review at D37368. The returned thunk is cast to the
appropriate type in the SymbolTable, and the constant symbol's body is
not needed directly, so avoid the assignment. NFC
llvm-svn: 312391
If a symbol is locally defined and is DLL imported in another
translation unit, and the object with the locally defined version is
loaded prior to the imported version, then the linker will fail to
resolve the definition of the thunk and return the locally defined
symbol. This will then be attempted to be cast to an import thunk,
which will clearly fail.
Only return the thunk if the symbol is inserted or a thunk is created.
Otherwise, report a duplication error.
llvm-svn: 312386
writeArchive returned a pair, but the first element of the pair is always
its first argument on failure, so it doesn't make sense to return it from
the function. This patch change the return type so that it does't return it.
Differential Revision: https://reviews.llvm.org/D37313
llvm-svn: 312177
This reverts commit r312171 because it is pointed out that that's not a
correct fix (see https://bugs.llvm.org/show_bug.cgi?id=32674#c14) and
also because it broke buildbots.
llvm-svn: 312174
MSVC link.exe supports nested static libraries. That is, an .a file can
contain other .a file as its member. It is reported that MySQL actually
depends on this feature.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32674
llvm-svn: 312171
Various classes have `Symtab` member variables even though we have
lld::coff::Symtab variable because previous attempts to make COFF lld's
internal structure resemble to ELF's was incomplete. This patch finishes
that job by removing member variables.
llvm-svn: 311938
Summary:
ArgParser created an instance of COFFOptTable on stack to use it to
parser command line arguments. Parsed arguments were then returned from
the function as InputArgList. This was safe because InputArgList referred
only statically-allocated InfoTable.
That is not a safe assumption after https://reviews.llvm.org/D36782,
which changes the type of its internal table from ArrayRef to std::vector.
To make lld work with that patch, we need to keep an instance of
COFFOptTable at least as long as an InputArgList is alive. This patch
does that.
Reviewers: yamaguchi
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37217
llvm-svn: 311930
Summary: Now that the llvm-mt manifest merging libraries are complete, we may use them to merge manifests instead of needing to shell out to mt.exe.
Subscribers: mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D36255
llvm-svn: 311424
When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what actually is exported from
the DLL.
This restores the behaviour of renamed exports to what it was in
4.0.
Differential Revision: https://reviews.llvm.org/D36634
llvm-svn: 310992
Since SVN r303491 and r304573, LLD used the COFFImportLibrary
functions from LLVM. These only had two names, Name and ExtName,
which wasn't enough to convey all the details of stdcall functions.
Stdcall functions got the wrong symbol name in the import library
itself in r303491, which is why it was reverted in r304561. When
re-landed and fixed in r304573 (after adding a test in r304572),
the symbol name itself in the import library ended up right, but the
name type of the import library entry was wrong.
This had the effect that linking to the import library succeeded
(contrary to in r303491, where linking to such an import library
failed), but at runtime, the symbol wouldn't be found in the DLL
(since the caller linked to the stdcall decorated name).
Differential Revision: https://reviews.llvm.org/D36545
llvm-svn: 310989
I'm explicitly ignoring the warning by casting to void instead of
deleting the local assignment, because it's confusing to see a
function that fails when its return value evaluates to true.
But when you see that it's a std::error_code, it makes more sense.
llvm-svn: 310965
Previously, our algorithm to compute a build id involved hashing the
executable and storing that as the GUID in the CV Debug Record chunk,
and setting the age to 1.
This breaks down in one very obvious case: a user adds some newlines to
a file, rebuilds, but changes nothing else. This causes new line
information and new file checksums to get written to the PDB, meaning
that the debug info is different, but the generated code would be the
same, so we would write the same build over again with an age of 1.
Anyone using a symbol cache would have a problem now, because the
debugger would open the executable, look at the age and guid, find a
matching PDB in the symbol cache and then load it. It would never copy
the new PDB to the symbol cache.
This patch implements the canonical Windows algorithm for updating
a build id, which is to check the existing executable first, and
re-use an existing GUID while bumping the age if it already
exists.
Differential Revision: https://reviews.llvm.org/D36758
llvm-svn: 310961
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
We don't have the right algorithm for copying S_UDT symbols
from object files to the globals stream, and having it wrong
is worse than not having it at all, since it breaks display
of local variables of UDT types (for example, "dv Foo" fails
in our current implementation, but succeeds if the S_UDT records
are omitted). Omit them until we fix the algorithm.
llvm-svn: 310867
The linker module contains a symbol of type S_COMPILE3 which
contains various information about the compiler and linker used
to create the PDB, such as the name of the linker, the target
machine, and the linker version. Interestingly, if we set the
version string to 0.0.0.0, then when trying to view local
variables WinDbg emits an error that private symbols are not
present. By setting this to a valid MSVC linker version string,
local variables can display.
As such, even though it is not representative of LLVM's version
information, we need this for compatibility.
llvm-svn: 310755
PDBs need to contain 1 module for each object file/compiland,
and a special one synthesized by the linker. This one contains
a symbol record for each output section in the executable with
its address information. This patch adds such symbols to the
linker module. Note that we also are supposed to add an
S_COFFGROUP symbol for what appears to be each input section that
contributes to each output section, but it's not entirely clear
how to generate these yet, so I'm leaving that for a separate
patch.
llvm-svn: 310754
Previously we were writing an empty globals stream. Windows
tools interpret this as "private symbols are not present in
this PDB", even when they are, so we need to fix this. Regardless,
without it we don't have information about global variables, so
we need to fix it anyway. This patch does that.
With this patch, the "lm" command in WinDbg correctly reports
that we have private symbols available, but the "dv" command
still refuses to display local variables.
Differential Revision: https://reviews.llvm.org/D36535
llvm-svn: 310743
The publics stream and globals stream are very similar. They both
contain a list of hash buckets that refer into a single shared stream,
the symbol record stream. Because of the need for each builder to manage
both an independent hash stream as well as a single shared record
stream, making the two builders be independent entities is not the right
design. This patch merges them into a single class, of which only a
single instance is needed to create all 3 streams. PublicsStreamBuilder
and GlobalsStreamBuilder are now merged into the single GSIStreamBuilder
class, which writes all 3 streams at once.
Note that this patch does not contain any functionality change. So we're
still not yet writing any records to the globals stream. All we're doing
is making it so that when we do start writing records to the globals,
this refactor won't have to be part of that patch.
Differential Revision: https://reviews.llvm.org/D36489
llvm-svn: 310438
The compiler outputs PROC32_ID symbols into the object files
for functions, and these symbols have an embedded type index
which, when copied to the PDB, refer to the IPI stream. However,
the symbols themselves are also converted into regular symbols
(e.g. S_GPROC32_ID -> S_GPROC32), and type indices in the regular
symbol records refer to the TPI stream. So this patch applies
two fixes to function records.
1. It converts ID symbols to the proper non-ID record type.
2. After remapping the type index from the object file's index
space to the PDB file/IPI stream's index space, it then
remaps that index to the TPI stream's index space by.
Besides functions, during the remapping process we were also
discarding symbol record types which we did not recognize.
In particular, we were discarding S_BPREL32 records, which is
what MSVC uses to describe local variables on the stack. So
this patch fixes that as well by copying them to the PDB.
Differential Revision: https://reviews.llvm.org/D36426
llvm-svn: 310394
Zachary Turner