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
LinkerDriver::inferSubsystem() used to do Symtab->findUnderscore("WinMain"),
but WinMain is stdcall in 32-bit and is hence is called _WinMain@16. Instead,
Symtab->findMangle(mangle("WinMain")) needs to be called.
But since LinkerDriver::inferSubsystem() and LinkerDriver::findDefaultEntry()
both need to call this, introduce a common helper function for this and call it
from both places. (Also call it for "main" for consistency, even though
findUnderscore() is enough for main since that's __cdecl on 32-bit).
This also exposed a bug for /nodefaultlib entrypoint inference: The code here
called findMangle(Sym) instead of findMangle(mangle(Sym)), again doing the
wrong thing on 32-bit. Fix that too.
While here, make Driver::mangle() a static free function.
https://reviews.llvm.org/D50184
llvm-svn: 338877
Some lit tests that call llvm-ar use the 'r' flag. If the target archive
already exists and is in a corrupt state, this can cause the test to fail. We
have added 'rm -f' calls before the llvm-ar calls to increase the
robustness of the tests.
Differential revision: https://reviews.llvm.org/D49184
llvm-svn: 338705
This was useful for LTO bringup in lld-link while lld couldn't write PDBs. Now
that it can, this should no longer be needed. Hopefully the flag is obscure
enough and recent enough, that nobody uses it – but if somebody should use it,
they should be able to just stop passing it and things should continue to work.
https://reviews.llvm.org/D50139
llvm-svn: 338615
Discard them unless they have been associated by other means (yet
uimplemented).
According to MS link.exe, such sections are illegal, but MinGW setups
use them in their take on associative comdats.
This avoids leaving references to the bogus SectionChunk* PendingComdat,
which cannot be dereferenced.
This fixes PR38183.
Differential Revision: https://reviews.llvm.org/D49653
llvm-svn: 338064
Previously, the error messages didn't contain symbol name because we
didn't read a symbol name for these error messages.
Differential Revision: https://reviews.llvm.org/D49762
llvm-svn: 337863
If a binary is stripped, which can remove discardable sections (except
for the .reloc section, which also is marked as discardable as it isn't
loaded at runtime, only read by the loader), the .reloc section should
be first of them, in order not to create gaps in the image.
Previously, binaries with relocations were broken if they were stripped
by GNU binutils strip. Trying to execute such binaries produces an error
about "xx is not a valid win32 application".
This fixes GNU binutils bug 23348.
Prior to SVN r329370 (which didn't intend to have functional changes),
the code for moving discardable sections to the end didn't clearly
express how other discardable sections should be ordered compared to
.reloc, but the change retained the exact same end result as before.
After SVN r329370, the code (and comments) more clearly indicate that
it tries to make the .reloc section the absolutely last one; this patch
changes that.
This matches how GNU binutils ld sorts .reloc compared to dwarf debug
info sections.
Differential Revision: https://reviews.llvm.org/D49351
Signed-off-by: Martin Storsjö <martin@martin.st>
llvm-svn: 337598
For dwarf debug info, an executable normally either contains the debug
info, or it is stripped out. To reduce the storage needed (slightly)
for the debug info kept separately from the released, stripped binaries,
one can choose to only copy the debug data from the original executable
(essentially the reverse of the strip operation), producing a file with
only debug info.
When copying the debug data from an executable with GNU objcopy,
the build id and debug directory need to reside in a separate section,
as this will be kept while the rest of the .rdata section is removed.
Differential Revision: https://reviews.llvm.org/D49352
llvm-svn: 337526
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
Dwarf debug info contains some data that contains absolute addresses.
Since these sections are discardable and aren't loaded at runtime,
there's no point in adding base relocations for them.
This makes sure that after stripping out dwarf debug info, there are no
base relocations that point to nonexistent sections.
Differential Revision: https://reviews.llvm.org/D49350
llvm-svn: 337438
Some Microsoft tools (e.g. new versions of WPA) fail when the
COFF Debug Directory contains a path to the PDB that contains
dots, such as D:\foo\./bar.pdb. Remove dots before writing this
path.
This fixes pr38126.
llvm-svn: 336873
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
They were failing in Chromium's packaging builds with:
C:\b\rr\tmphqfaff\w\src\third_party\llvm\tools\lld\test\COFF\pdb-globals-dia-vfunc-collision2.test:24:8:
error: expected string not found in input
CHECK: func [0x00001060+ 0 - 0x0000106c-12 | sizeof= 12] (FPO) virtual int __cdecl A132()
^
<stdin>:8:11: note: scanning from here
struct S [sizeof = 8] {
^
<stdin>:9:2: note: possible intended match here
func [0x00001060+ 0 - 0x0000106c-12 | sizeof= 12] (FPO) virtual int __cdecl S::A132()
^
Maybe due to different DIA versions.
llvm-svn: 336424
We add an option to dump the entire global / public symbol record
stream. Previously we would dump globals or publics, but not both.
And when we did dump them, we would always dump them in the order
they were referenced by the corresponding hash streams, not in
the order they were serialized in. This patch adds a lower level
mode that just dumps the whole stream in serialization order.
Additionally, when dumping global-extras, we now dump the hash
bitmap as well as the record offset instead of dumping all zeros
for the offsets.
llvm-svn: 336407
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
With this set, we retain the symbol table, but skip the actual debug
information.
This is meant to be used by the MinGW frontend.
Differential Revision: https://reviews.llvm.org/D48745
llvm-svn: 335946
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
`lld-link foo.lib /wholearchive:foo.lib` should work the same way as
`lld-link /wholearchive:foo.lib foo.lib`. Previously, /wholearchive in
the former case was ignored.
Differential Revision: https://reviews.llvm.org/D47565
llvm-svn: 334552
When running with linker GC (`-opt:ref`), defined imported symbols that
are referenced but then dropped by GC end up with their `Location`
member being nullptr, which means `getChunk()` returns nullptr for them
and attempting to call `getChunk()->getOutputSection()` causes a crash
from the nullptr dereference. Check for `getChunk()` being nullptr and
bail out early to avoid the crash.
Differential Revision: https://reviews.llvm.org/D48092
llvm-svn: 334548
If building lld without x86 support, tests that require that support should
be treated as unsupported, not errors.
Tested using:
1. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64;X86'
make check-lld
=>
Expected Passes : 1406
Unsupported Tests : 287
2. cmake '-DLLVM_TARGETS_TO_BUILD=AArch64'
make check-lld
=>
Expected Passes : 410
Unsupported Tests : 1283
Patch by Joel Jones
Differential Revision: https://reviews.llvm.org/D47748
llvm-svn: 334095
Rather than using a loop to compare symbol RVAs to the starting RVAs of
sections to determine which section a symbol belongs to, just get the
output section of a symbol directly via its chunk, and bail if the
symbol doesn't have an output section, which avoids having to hardcode
logic for handling dead symbols, CodeView symbols, etc. This was
suggested by Reid Kleckner; thank you.
This also fixes writing out symbol tables in the presence of RVA table
input sections (e.g. .sxdata and .gfids). Such sections aren't written
to the output file directly, so their RVA is 0, and the loop would thus
fail to find an output section for them, resulting in a segfault. Extend
some existing tests to cover this case.
Fixes PR37584.
Differential Revision: https://reviews.llvm.org/D47391
llvm-svn: 333450
Previously we emitted 20-byte SHA1 hashes. This is overkill
for identifying debug info records, and has the negative side
effect of making object files bigger and links slower. By
using only the last 8 bytes of a SHA1, we get smaller object
files and ~10% faster links.
This modifies the format of the .debug$H section by adding a new
value for the hash algorithm field, so that the linker will still
work when its object files have an old format.
Differential Revision: https://reviews.llvm.org/D46855
llvm-svn: 332669
The prefix includes type kind, which is important to preserve. Two
different type leafs can easily have the same interior record contents
as another type.
We ran into this issue in PR37492 where a bitfield type record collided
with a const modifier record. Their contents were bitwise identical, but
their kinds were different.
llvm-svn: 332664
Previously we would always write a hash of the binary into the
PE file, for reproducible builds. This breaks AppCompat, which
is a feature of Windows that relies on the timestamp in the PE
header being set to a real value (or at the very least, a value
that satisfies certain properties).
To address this, we put the old behavior of writing the hash
behind the /Brepro flag, which mimics MSVC linker behavior. We
also match MSVC default behavior, which is to write an actual
timestamp to the PE header. Finally, we add the /TIMESTAMP
option (an lld extension) so that the user can specify the exact
value to be used in case he/she manually constructs a value which
is both reproducible and satisfies AppCompat.
Differential Revision: https://reviews.llvm.org/D46966
llvm-svn: 332613
This is needed to avoid merging two functions with identical
instructions but different xdata. It also reduces binary size by
deduplicating identical pdata sections.
Fixes PR35337.
Differential Revision: https://reviews.llvm.org/D46672
llvm-svn: 332169
We discovered (crbug.com/838449#c24) that string tail merging can
negatively affect compressed binary size, so provide a flag to turn
it off for users who care more about compressed size than uncompressed
size.
Differential Revision: https://reviews.llvm.org/D46780
llvm-svn: 332149
Previously this was only supported when specified on the command line
or in directives.
Differential Revision: https://reviews.llvm.org/D46244
llvm-svn: 331900
Now only IMAGE_REL_ARM64_ABSOLUTE and IMAGE_REL_ARM64_TOKEN
are unhandled.
Also add range checks for the existing BRANCH26 relocation.
Differential Revision: https://reviews.llvm.org/D46354
llvm-svn: 331505
Martin Storsjo