I need the comdat selection for PR40094. To keep the patch for that smaller,
I'm adding it here, and as a first application I'm using it to reject
associative comdats referring to earlier associative comdats. Depends on
D56929; together with that all associative comdats referring to other
associative comdats are now rejected.
Differential Revision: https://reviews.llvm.org/D56931
llvm-svn: 352254
Previously, we assumed that .rdata is zero-filled, so when writing
an COFF import table, we didn't write anything if the data is zero.
That assumption was wrong because .rdata can be merged with .text.
If .rdata is merged with .text, they are initialized with 0xcc which
is a trap instruction.
This patch removes that assumption from code.
Should be merged to 8.0 branch as this is a regression.
Fixes https://bugs.llvm.org/show_bug.cgi?id=39826
Differential Revision: https://reviews.llvm.org/D57168
llvm-svn: 352082
Currently, if an associative comdat appears after the comdat it's associated
with it's processed immediately, else it's deferred until the end of the object
file. I found this confusing to think about while working on PR40094, so this
makes it so that associated comdats are always processed at the end of the
object file. This seems to be perf-neutral and simpler.
Now there's a natural place to reject the associated comdats referring to later
associated comdats (associated comdats referring to associated comdats is
invalid per COFF spec) that, so reject those. (A later patch will reject
associated comdats referring to earlier comdats.)
Differential Revision: https://reviews.llvm.org/D56929
llvm-svn: 351917
LLD's performance on PGO instrumented Windows binaries was still not
great even with the fix in D56955; out of the 2m41s linker runtime,
around 2 minutes were still being spent in ICF. I looked into this more
closely and discovered that the vast majority of the runtime was being
spent segregating .pdata sections with the following relocation chain:
.pdata -> identical .text -> unique PGO counter (not eligible for ICF)
This patch causes us to perform 2 rounds of relocation hash
propagation, which allows the hash for the .pdata sections to
incorporate the identifier from the PGO counter. With that, the amount
of time spent in ICF was reduced to about 2 seconds. I also found that
the same change led to a significant ICF performance improvement in a
regular release build of Chromium's chrome_child.dll, where ICF time
was reduced from around 1s to around 700ms.
With the same change applied to the ELF linker, median of 100 runs
for lld-speed-test/chrome reduced from 4.53s to 4.45s on my machine.
I also experimented with increasing the number of propagation rounds
further, but I did not observe any further significant performance
improvements linking Chromium or Firefox.
Differential Revision: https://reviews.llvm.org/D56986
llvm-svn: 351899
It turns out that sections in PGO instrumented object files on Windows
contain a large number of relocations pointing to themselves. With
r347429 this can cause many sections to receive the same hash (usually
zero) as a result of a section's hash being xor'ed with itself.
This patch causes the COFF and ELF linkers to avoid this problem
by adding the hash of the relocated section instead of xor'ing it.
On my machine this causes the regressing test case
provided by Mozilla to terminate in 2m41s.
Differential Revision: https://reviews.llvm.org/D56955
llvm-svn: 351898
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
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
My main motivation is that I can never remember /nodefaultlib and
`lld-link /? | grep no` didn't display it due to it not having a help string.
Differential Revision: https://reviews.llvm.org/D56502
llvm-svn: 350750
Saves up to 1.3 sec on large PDBs.
Figures below are for the "Globals Stream Layout" pass:
Before This patch
Large EXE (PDB is ~2 GB) 3330 ms 2022 ms
Large EXE (PDB is ~2 GB) 2680 ms 1608 ms
Large DLL (PDB is ~1 GB) 1455 ms 938 ms
Large DLL (PDB is ~800 MB) 1215 ms 800 ms
Small DLL (PDB is ~200 MB) 224 ms 146 ms
Differential Revision: https://reviews.llvm.org/D56334
llvm-svn: 350452
In PDBs, symbol records must be aligned to four bytes. However, in the
object file, symbol records may not be aligned. MSVC does not pad out
symbol records to make sure they are aligned. That means the linker has
to do extra work to insert the padding. Currently, LLD calculates the
required space with alignment, and copies each record one at a time
while padding them out to the correct size. It has a fast path that
avoids this copy when the records are already aligned.
This change fixes a bug in that codepath so that the copy is actually
saved, and tweaks LLVM's symbol record emission to align symbol records.
Here's how things compare when doing a plain clang Release+PDB build:
- objs are 0.65% bigger (negligible)
- link is 3.3% faster (negligible)
- saves allocating 441MB
- new LLD high water mark is ~1.05GB
llvm-svn: 349431
When calling BinaryStreamArray::drop_front(), if the stream
is skewed it means we must never drop the first bytes of the
stream since offsets which occur in records assume the existence
of those bytes. So if we want to skip the first record in a
stream, then what we really want to do is just set the begin
pointer to the next record. But we shouldn't actually remove
those bytes from the underlying view of the data.
llvm-svn: 349066
Previously these were dropped. We now understand them sufficiently
well to start emitting them. From the debugger's perspective, this
now enables us to have debug info about typedefs (both global and
function-locally scoped)
Differential Revision: https://reviews.llvm.org/D55228
llvm-svn: 348306
We initialize .text section with 0xcc (INT3 instruction), so we need to
explicitly write data even if it is zero if it can be in a .text section.
If you specify /merge:.rdata=.text, .rdata (which contains .idata) is put
to .text, so we need to do this.
Fixes https://bugs.llvm.org/show_bug.cgi?id=39826
Differential Revision: https://reviews.llvm.org/D55098
llvm-svn: 348000
The number of sections is used in assignAddresses (in
finalizeAddresses) and the space for all sections is permanent from
that point on, even if we later decide we won't write some of them.
The VirtualSize field also gets calculated in assignAddresses, so we
need to manually check whether the section is empty here instead.
Differential Revision: https://reviews.llvm.org/D54495
llvm-svn: 347704
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
GNU ld, which doesn't generate PDBs, can optionally generate a
build id by passing the --build-id option. LLD's MinGW frontend knows
about this option but ignores it, as I had falsely assumed that LLD
already generated build IDs even in those cases.
If debug info is requested and no PDB path is set, generate a
build id signature as a hash of the binary itself. This allows
associating a binary to a minidump, even if debug info isn't
written in PDB form by the linker.
Differential Revision: https://reviews.llvm.org/D54828
llvm-svn: 347645
Summary:
MSVC does this, and we should to.
The .gfids table is a table of RVAs, so it's impossible for a DLL to
indicate that an imported symbol is address taken. Therefore, exports
appear to be listed as address taken by the DLL that exports them.
This fixes an issue that Firefox ran into here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1485016#c12
In Firefox, the export directive came from a .def file, but we need to
do this for any kind of export.
Reviewers: dmajor, hans, amccarth, alex
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54723
llvm-svn: 347623
Summary: They have an additional `ThreadsEnabled` check, which does not matter much.
Reviewers: pcc, ruiu, rnk
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54812
llvm-svn: 347587
Previously we were taking over 13 minutes to link Firefox's xul.dll
on ARM64; this reduces link time to around 18s on my machine.
The root cause of the problem was that all of the input .pdata sections
had the same unrelocated section data and therefore the same hash,
which made segregation quadratic in the number of .pdata sections. The
reason why we weren't observing this on other architectures was that
ARM has a different .pdata format. On non-ARM the format is (start
address, end address, .xdata), which caused the size of the function
to appear in the unrelocated section data where the end address field
is. However, the ARM format omits the end address field.
Fixes PR39667.
Differential Revision: https://reviews.llvm.org/D54809
llvm-svn: 347429
Don't use a uint32_t*, use a ulittle32_t* to make this correct
on big endian systems.
Patch by James Clarke
Differential Revision: https://reviews.llvm.org/D54421
llvm-svn: 347349
- Make mergeSymbolRecords a method of PDBLinker to reduce the number of
parameters it needs.
- Remove a stale FIXME comment about error handling. We already drop
unknown symbol records, log them, and continue.
- Update a comment about why we're copying the symbol record. We do it
to realign the record. We can already mutate the symbol record memory,
it's memory allocated by relocateDebugChunk.
- Avoid the extra `CVSymbol NewSym` variable. We can mutate Sym in
place, which is best, since we're mutating the underlying record anyway.
llvm-svn: 346817
Summary:
Reuse the "referenced by" note diagnostic code that we already use for
undefined symbols. In my case, it turned this:
lld-link: error: relocation against symbol in discarded section: .text
lld-link: error: relocation against symbol in discarded section: .text
...
Into this:
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M)
>>> referenced by libANGLE.lib(CompilerGL.obj):(.SCOVP$M)
...
lld-link: error: relocation against symbol in discarded section: .text
>>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M)
>>> referenced by obj/third_party/angle/libGLESv2/entry_points_egl_ext.obj:(.SCOVP$M)
...
I think the new output is more useful.
Reviewers: ruiu, pcc
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D54240
llvm-svn: 346427
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
Normally one wouldn't run into that case, but it is possible with
a little creative ordering of special libraries.
Differential Revision: https://reviews.llvm.org/D53388
llvm-svn: 344776
This a resubmission of a patch which was previously reverted
due to breaking several lld tests. The issues causing those
failures have been fixed, so the patch is now resubmitted.
---Original Commit Message---
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344377
This was originally causing some test failures on non-Windows
platforms, which required fixes in the compiler and linker. After
those fixes, however, other tests started failing. Reverting
temporarily until I can address everything.
llvm-svn: 344279
While it doesn't make a *ton* of sense for POSIX paths to be
in PDBs, it's possible to occur in real scenarios involving
cross compilation.
The tools need to be able to handle this, because certain types
of debugging scenarios are possible without a running process
and so don't necessarily require you to be on a Windows system.
These include post-mortem debugging and binary forensics (e.g.
using a debugger to disassemble functions and examine symbols
without running the process).
There's changes in clang, LLD, and lldb in this patch. After
this the cross-platform disassembly and source-list tests pass
on Linux.
Furthermore, the behavior of LLD can now be summarized by a much
simpler rule than before: Unless you specify /pdbsourcepath and
/pdbaltpath, the PDB ends up with paths that are valid within
the context of the machine that the link is performed on.
Differential Revision: https://reviews.llvm.org/D53149
llvm-svn: 344269
When these are accessed with load/store instructions on ARM64,
it becomes strictly necessary to have them properly aligned.
This fixes PR39228.
Differential Revision: https://reviews.llvm.org/D53128
llvm-svn: 344264
This allows using #pragma comment(lib, "foo") in MinGW built code,
if built with -fms-extensions. (This works for system libraries and
static libraries only, as it doesn't try to look for .dll.a. As
ld.bfd doesn't support embedded defaultlib directives, this isn't
in widespread use among mingw users.)
Differential Revision: https://reviews.llvm.org/D53017
llvm-svn: 344124
Summary: Before, OptTable::PrintHelp append "[options] <inputs>" to its parameter `Help`. It is more flexible to change its semantic to `Usage` and let user customize the usage line.
Reviewers: rupprecht, ruiu, espindola
Reviewed By: rupprecht
Subscribers: emaste, sbc100, arichardson, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D53054
llvm-svn: 344099
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
