Summary:
That unless the user requested an output object (--lto-obj-path), the an
unused empty combined module is not emitted.
This changed is helpful for some target (ex. RISCV-V) which encoded the
ABI info in IR module flags (target-abi). Empty unused module has no ABI
info so the linker would get the linking error during merging
incompatible ABIs.
Reviewers: tejohnson, espindola, MaskRay
Subscribers: emaste, inglorion, arichardson, hiraditya, simoncook, MaskRay, steven_wu, dexonsmith, PkmX, dang, lenary, s.egerton, luismarques, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78988
Heap profiling with ETW shows that LLD performs 4,053,721 heap
allocations over its lifetime, and ~800,000 of them come from
assocEquals. These vectors are created just to do a comparison, so fuse
the comparison into the loop and avoid the allocation.
ICF is overall a small portion of the time spent linking, and I did not
measure overall throughput improvements from this change above the noise
threshold. However, these show up in the heap profiler, and the work is
done, so we might as well land it if the code is clear enough.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D79297
This particular overload allocates memory, and we do this for every
S_[GL]PROC32_ID record. Instead, hardcode the offset of the typeindex
that we are looking for in the LF_[MEM]FUNC_ID record. We already
assumed that looking up the item index already found a record of this
kind.
Otherwise an ArgumentParser is constructed for every directive section,
and that involves copying the entire table of options into a vector.
There is no need for this, just have one option table.
This generalizes the main Windows command line tokenizer to be able to
produce StringRef substrings as well as freshly copied C strings. The
implementation is still shared with the normal tokenizer, which is
important, because we have unit tests for that.
.drective sections can be very long. They can potentially list up to
every symbol in the object file by name. It is worth avoiding these
string copies.
This saves a lot of memory when linking chrome.dll with PGO
instrumentation:
BEFORE AFTER % IMP
peak memory: 6657.76MB 4983.54MB -25%
real: 4m30.875s 2m26.250s -46%
The time improvement may not be real, my machine was noisy while running
this, but that the peak memory usage improvement should be real.
This change may also help apps that heavily use dllexport annotations,
because those also use linker directives in object files. Apps that do
not use many directives are unlikely to be affected.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D79262
This speeds up linking chrome.dll with PGO instrumentation by 13%
(154271ms -> 134033ms).
LLVM's Option library is very slow. In particular, it allocates at least
one large-ish heap object (Arg) for every argument. When PGO
instrumentation is enabled, all the __profd_* symbols are added to the
@llvm.used list, which compiles down to these /INCLUDE: directives. This
means we have O(#symbols) directives to parse in the section, so we end
up allocating an Arg for every function symbol in the object file. This
is unnecessary.
To address the issue and speed up the link, extend the fast path that we
already have for /EXPORT:, which has similar scaling issues.
I promise that I took a hard look at optimizing the Option library, but
its data structures are very general and would need a lot of cleanup. We
have accumulated lots of optional features (option groups, aliases,
multiple values) over the years, and these are now properties of every
parsed argument, when the vast majority of arguments do not use these
features.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D78845
Use the unique filenames that are used when /lldsavetemps is passed.
After this change, module names for LTO blobs in PDBs will be unique.
Visual Studio and probably other debuggers expect module names to be
unique.
Revert some changes from 1e0b158db (2017) that are no longer necessary
after removing MSVC LTO support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D78221
The alignment of ARM64 range extension thunks was fixed in
7c81649219, but ARM range extension thunks, and import
and delay import thunks also need aligning (like all code on ARM
platforms).
I'm adding a test for alignment of ARM64 import thunks - not
specifically adding tests for misalignment of all of them though.
Differential Revision: https://reviews.llvm.org/D77796
Summary:
/PDBSTREAM:<name>=<file> adds the contents of <file> to stream <name> in the resulting PDB.
This allows native uses with workflows that (for example) add srcsrv streams to PDB files to provide a location for the build's source files.
Results should be equivalent to linking with lld-link, then running Microsoft's pdbstr tool with the command line:
pdbstr.exe -w -p:<PDB LOCATION> -s:<name> -i:<file>
except in cases where the named stream overlaps with a default named stream, such as "/names". In those cases, the added stream will be overridden, making the /pdbstream option a no-op.
Reviewers: thakis, rnk
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D77310
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
As of a while ago, lld groups all undefined references to a single
symbol in a single diagnostic. Back then, I made it so that we
print up to 10 references to each undefined symbol.
Having used this for a while, I never wished there were more
references, but I sometimes found that this can print a lot of
output. lld prints up to 10 diagnostics by default, and if
each has 10 references (which I've seen in practice), and each
undefined symbol produces 2 (possibly very long) lines of output,
that's over 200 lines of error output.
Let's try it with just 3 references for a while and see how
that feels in practice.
Differential Revision: https://reviews.llvm.org/D77017
DWARF sections are typically live and not COMDAT, so they would be
treated as GC roots. Enabling DWARF would essentially keep all code with
debug info alive, preventing any section GC.
Fixes PR45273
Reviewed By: mstorsjo, MaskRay
Differential Revision: https://reviews.llvm.org/D76935
Before this patch, it wasn't possible to extend the ThinLTO threads to all SMT/CMT threads in the system. Only one thread per core was allowed, instructed by usage of llvm::heavyweight_hardware_concurrency() in the ThinLTO code. Any number passed to the LLD flag /opt:lldltojobs=..., or any other ThinLTO-specific flag, was previously interpreted in the context of llvm::heavyweight_hardware_concurrency(), which means SMT disabled.
One can now say in LLD:
/opt:lldltojobs=0 -- Use one std::thread / hardware core in the system (no SMT). Default value if flag not specified.
/opt:lldltojobs=N -- Limit usage to N threads, regardless of usage of heavyweight_hardware_concurrency().
/opt:lldltojobs=all -- Use all hardware threads in the system. Equivalent to /opt:lldltojobs=$(nproc) on Linux and /opt:lldltojobs=%NUMBER_OF_PROCESSORS% on Windows. When an affinity mask is set for the process, threads will be created only for the cores selected by the mask.
When N > number-of-hardware-threads-in-the-system, the threads in the thread pool will be dispatched equally on all CPU sockets (tested only on Windows).
When N <= number-of-hardware-threads-on-a-CPU-socket, the threads will remain on the CPU socket where the process started (only on Windows).
Differential Revision: https://reviews.llvm.org/D75153
Added support for /map and /map:[filepath].
The output was derived from Microsoft's Link.exe output when using that same option.
Note that /MAPINFO support was not added.
The previous implementation of MapFile.cpp/.h was meant for /lldmap, and was renamed to LLDMapFile.cpp/.h
MapFile.cpp/.h is now for /MAP
However, a small fix was added to lldmap, replacing a std::sort with std::stable_sort to enforce reproducibility.
Differential Revision: https://reviews.llvm.org/D70557
Instead, use `using namespace lld(::coff)`, and fully qualify the names
of free functions where they are defined in cpp files.
This effectively reverts d79c3be618 to follow the new style guide added
in 236fcbc21a.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D74882
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
When annotating a symbol with __declspec(selectany), Clang assigns it
comdat 2 while GCC assigns it comdat 3. This patch enables two object
files that contain a __declspec(selectany) symbol, one created by gcc
and the other by clang, to be linked together instead of issuing a
duplicate symbol error.
Differential Revision: https://reviews.llvm.org/D73139
RangeExtensionThunkARM64 is created for out-of-range branches on Windows ARM64
because branch instructions has limited bits to encode target address.
Currently, RangeExtensionThunkARM64 is appended to its referencing COFF section
from object file at link time without any alignment requirement, so if size of
the preceding COFF section is not aligned to instruction boundary (4 bytes),
RangeExtensionThunkARM64 will emit thunk instructions at unaligned address
which is never a valid branch target on ARM64, and usually triggers invalid
instruction exception when branching to it.
This PR fixes it by requiring such thunks to align at 4 bytes.
Differential revision: https://reviews.llvm.org/D72473
down to pass builder in ltobackend.
Currently CodeGenOpts like UnrollLoops/VectorizeLoop/VectorizeSLP in clang
are not passed down to pass builder in ltobackend when new pass manager is
used. This is inconsistent with the behavior when new pass manager is used
and thinlto is not used. Such inconsistency causes slp vectorization pass
not being enabled in ltobackend for O3 + thinlto right now. This patch
fixes that.
Differential Revision: https://reviews.llvm.org/D72386
Both MS link.exe and GNU ld.bfd handle it this way; one can have
multiple object files defining the same absolute symbols, as long
as it defines it to the same value. But if there are multiple absolute
symbols with differing values, it is treated as an error.
Differential Revision: https://reviews.llvm.org/D71981
Summary:
I used this information to motivate splitting up the Intrinsic::ID enum
(5d986953c8) and adding a key method to
clang::Sema (586f65d31f) which saved a
fair amount of object file size.
Example output for clang.pdb:
Top 10 types responsible for the most TPI input bytes:
index total bytes count size
0x3890: 8,671,220 = 1,805 * 4,804
0xE13BE: 5,634,720 = 252 * 22,360
0x6874C: 5,181,600 = 408 * 12,700
0x2A1F: 4,520,528 = 1,574 * 2,872
0x64BFF: 4,024,020 = 469 * 8,580
0x1123: 4,012,020 = 2,157 * 1,860
0x6952: 3,753,792 = 912 * 4,116
0xC16F: 3,630,888 = 633 * 5,736
0x69DD: 3,601,160 = 985 * 3,656
0x678D: 3,577,904 = 319 * 11,216
In this case, we can see that record 0x3890 is responsible for ~8MB of
total object file size for objects in clang.
The user can then use llvm-pdbutil to find out what the record is:
$ llvm-pdbutil dump -types -type-index 0x3890
Types (TPI Stream)
============================================================
Showing 1 records.
0x3890 | LF_FIELDLIST [size = 4804]
- LF_STMEMBER [name = `WORDTYPE_MAX`, type = 0x1001, attrs = public]
- LF_MEMBER [name = `U`, Type = 0x37F0, offset = 0, attrs = private]
- LF_MEMBER [name = `BitWidth`, Type = 0x0075 (unsigned), offset = 8, attrs = private]
- LF_METHOD [name = `APInt`, # overloads = 8, overload list = 0x3805]
...
In this case, we can see that these are members of the APInt class,
which is emitted in 1805 object files.
The next largest type is ASTContext:
$ llvm-pdbutil dump -types -type-index 0xE13BE bin/clang.pdb
0xE13BE | LF_FIELDLIST [size = 22360]
- LF_BCLASS
type = 0x653EA, offset = 0, attrs = public
- LF_MEMBER [name = `Types`, Type = 0x653EB, offset = 8, attrs = private]
- LF_MEMBER [name = `ExtQualNodes`, Type = 0x653EC, offset = 24, attrs = private]
- LF_MEMBER [name = `ComplexTypes`, Type = 0x653ED, offset = 48, attrs = private]
- LF_MEMBER [name = `PointerTypes`, Type = 0x653EE, offset = 72, attrs = private]
...
ASTContext only appears 252 times, but the list of members is long, and
must be repeated everywhere it is used.
This was the output before I split Intrinsic::ID:
Top 10 types responsible for the most TPI input:
0x686C: 69,823,920 = 1,070 * 65,256
0x686D: 69,819,640 = 1,070 * 65,252
0x686E: 69,819,640 = 1,070 * 65,252
0x686B: 16,371,000 = 1,070 * 15,300
...
These records were all lists of intrinsic enums.
Reviewers: MaskRay, ruiu
Subscribers: mgrang, zturner, thakis, hans, akhuang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71437
One instance looks like a false positive:
lld/ELF/Relocations.cpp:1622:14: note: use reference type 'const std::pair<ThunkSection *, uint32_t> &' (aka 'cons
t pair<lld:🧝:ThunkSection *, unsigned int> &') to prevent copying
for (const std::pair<ThunkSection *, uint32_t> ts : isd->thunkSections)
It is not changed in this commit.
Previously this caused crashes in the reportDuplicate method.
A DefinedAbsolute doesn't have any InputFile attached to it, so we
can't report the file for the original symbol.
We could add an InputFile argument to SymbolTable::addAbsolute
only for the sake of error reporting, but even then it'd be assymetrical,
only pointing out the file containing the new conflicting definition,
not the original one.
Differential Revision: https://reviews.llvm.org/D71679
Remove the lld::enableColors function, as it just obscures which
stream it's affecting, and replace with explicit calls to the stream's
enable_colors.
Also, assign the stderrOS and stdoutOS globals first in link function,
just to ensure nothing might use them.
(Either change individually fixes the issue of using the old
stream, but both together seems best.)
Follow-up to b11386f9be.
Differential Revision: https://reviews.llvm.org/D70492
In lld we rarely use std::unique_ptr but instead allocate new instances
using lld::make<T>() so that they are deallocated at the end of linking.
This patch changes existing code so that that follows the convention.
Differential Revision: https://reviews.llvm.org/D70420
This change is for those who use lld as a library. Context:
https://reviews.llvm.org/D70287
This patch adds a new parmeter to lld::*::link() so that we can pass
an raw_ostream object representing stdout. Previously, lld::*::link()
took only an stderr object.
Justification for making stdoutOS and stderrOS mandatory: I wanted to
make link() functions to take stdout and stderr in that order.
However, if we change the function signature from
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stderrOS = llvm::errs());
to
bool link(ArrayRef<const char *> args, bool canExitEarly,
raw_ostream &stdoutOS = llvm::outs(),
raw_ostream &stderrOS = llvm::errs());
, then the meaning of existing code that passes stderrOS silently
changes (stderrOS would be interpreted as stdoutOS). So, I chose to
make existing code not to compile, so that developers can fix their
code.
Differential Revision: https://reviews.llvm.org/D70292
/align is not supposed to be used without /driver, so it makes sense
to warn if only /align is passed. MSVC link.exe warns on this too.
Differential Revision: https://reviews.llvm.org/D70163
This broke in 51dcb292cc, "[lld-link] diagnose undefined symbols
before LTO when possible" (very soon after the 9.0 branch, so
luckily the 9.0 release is unaffected).
The code for loading objects we believe might be needed for autoimport
(loadMinGWAutomaticImports()) does run before the new
reportUnresolvable() function, but it had a condition to only operate
on symbols from regular object files. This condition came from
resolveRemainingUndefines(), but as loadMinGWAutomaticImports() now
has to operate before the LTO, it has to operate on undefineds from
LTO objects as well.
Differential Revision: https://reviews.llvm.org/D70166
Recent versions of Microsoft's dumpbin tool cannot handle such PE files.
LLVM tools and GNU tools can, and use this to encode long section names
like ".debug_info", which is commonly used for DWARF. Don't do this in
mingw mode or when -debug:dwarf is passed, since the user probably wants
long section names for DWARF sections.
PR43754
Reviewers: ruiu, mstorsjo
Differential Revision: https://reviews.llvm.org/D69594
Also mention "basename" and "dirname" in Path.h since I tried
to find these functions by looking for these strings. It might
help others find them faster if the comments contain these strings.
No behavior change.
Differential Revision: https://reviews.llvm.org/D69458
As we now have code that parses the dwarf info for variable locations,
we can use that instead of relying on the higher level Symbolizer library,
reducing the previous two different dwarf codepaths into one.
Differential Revision: https://reviews.llvm.org/D69198
llvm-svn: 375391
This fixes the second part of PR42407.
For files with dwarf debug info, it manually loads and iterates
.debug_info to find the declared location of variables, to allow
reporting them. (This matches the corresponding code in the ELF
linker.)
For functions, it uses the existing getFileLineDwarf which uses
LLVMSymbolizer for translating addresses to file lines.
In object files with codeview debug info, only the source location
of duplicate functions is printed. (And even there, only for the
first input file. The getFileLineCodeView function requires the
object file to be fully loaded and initialized to properly resolve
source locations, but duplicate symbols are reported at a stage when
the second object file isn't fully loaded yet.)
Differential Revision: https://reviews.llvm.org/D68975
llvm-svn: 375218
This makes use of it slightly clearer, and makes it match the
same construct in the lld ELF linker.
Differential Revision: https://reviews.llvm.org/D68935
llvm-svn: 374869
A common pattern in Windows is to have all your precompiled headers
use an object named stdafx.obj. If you've got a project with many
different static libs, you might use a separate PCH for each one of
these.
During the final link step, a file from A might reference the PCH
object from A, but it will have the same name (stdafx.obj) as any
other PCH from another project. The only difference will be the
path. For example, A might be A/stdafx.obj while B is B/stdafx.obj.
The existing algorithm checks only the filename that was passed on
the command line (or stored in archive), but this is insufficient in
the case where relative paths are used, because depending on the
command line object file / library order, it might find the wrong
PCH object first resulting in a signature mismatch.
The fix here is to simply check whether the absolute path of the
PCH object (which is stored in the input obj file for the file that
references the PCH) *ends with* the full relative path of whatever
is specified on the command line (or is in the archive).
Differential Revision: https://reviews.llvm.org/D66431
llvm-svn: 374442
Similar to D67323, but for COFF. Many lld/COFF/ files already use
`namespace lld { namespace coff {`. Only a few need changing.
Reviewed By: ruiu
Differential Revision: https://reviews.llvm.org/D68772
llvm-svn: 374314
David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if present.
These checksums are essentially the same, so having multiple
implementations seems unnecessary. This replaces the CRC-32
implementation with the simpler one from JamCRC, and implements the
JamCRC interface in terms of CRC-32 since this means it can use zlib's
implementation when available, saving a few bytes and potentially making
it faster.
JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef.
This patch changes it to ArrayRef<uint8_t> which I think is the best
choice, and simplifies a few of the callers nicely.
Differential revision: https://reviews.llvm.org/D68570
llvm-svn: 374148
Fixes assert in addLinkerModuleCoffGroup() when using by-ordinal imports
only.
Patch by Stefan Schmidt.
Differential revision: https://reviews.llvm.org/D68352
llvm-svn: 374140
This patch adds /reproduce:<path> option to lld/COFF. This is an
lld-specific option, so we can name it freely. I chose /reproduce
over other names (e.g. /lldlinkrepro) for consistency with other lld
ports.
Differential Revision: https://reviews.llvm.org/D68381
llvm-svn: 373704
This reverts commit r371729 because /linkrepro option also exists
in Microsoft link.exe and their linker takes not a filename but a
directory name as an argument for /linkrepro.
Differential Revision: https://reviews.llvm.org/D68378
llvm-svn: 373703
This is useful for enforcing that builds are independent of the
environment; it can be used when all system library paths are added
via /libpath: already. It's similar ot cl.exe's /X flag.
Since it should also affect %LINK% (the other caller of
`Process::GetEnv` in lld/COFF), the early-option-parsing needs
to move around a bit. The options are:
- Add a manual loop over the argv ArrayRef and look for "/lldignoreenv".
This repeats the name of the flag in both Options.td and in
DriverUtils.cpp.
- Add yet another table.ParseArgs() call just for /lldignoreenv before
adding %LINK%.
- Use the existing early ParseArgs() that's there for --rsp-quoting and use
it for /lldignoreenv for %LINK% as well. This means --rsp-quoting
and /lldignoreenv can't be passed via %LINK%.
I went with the third approach.
Differential Revision: https://reviews.llvm.org/D67456
llvm-svn: 371852
from thin archives.
Currently lld adds the archive name to MemoryBufferRef identifiers in order to
ensure they are unique. For thin archives, since the file name is already unique and we
want to keep the original path to the file, don't add the archive name.
Differential Revision: https://reviews.llvm.org/D67295
llvm-svn: 371778
This makes lld-link behave like ld.lld. I don't see a reason for
the two drivers to have different behavior here.
While here, also make lld-link add a version.txt to the tar, like
ld.lld does.
Differential Revision: https://reviews.llvm.org/D67461
llvm-svn: 371729
Patch by Markus Böck.
PR42951: When linking an archive with members that have the same name linking
fails when using the -wholearchive option. This patch passes the index
of the member in the archive to the offset parameter to disambiguate the
member.
Differential Revision: https://reviews.llvm.org/D66239
llvm-svn: 371509
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
Summary:
This adds the -lto-obj-path option to lld-link. This can be
used to specify a path at which to write a native object file for
the full LTO part when using LTO unit splitting.
Reviewers: ruiu, tejohnson, pcc, rnk
Reviewed By: ruiu, rnk
Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65964
llvm-svn: 369559
This avoids producing an output file if errors appeared late in the
linking process (e.g. while fixing relocations, or as in the test,
while checking for multiple resources). If an output file is produced,
build tools might not retry building it on rebuilds, even if a previous
build failed due to the error return code.
Differential Revision: https://reviews.llvm.org/D66491
llvm-svn: 369445
This avoids confusing contextless error messages such as "No such file
or directory" if e.g. the pdb output file should be written to a
nonexistent directory. (This can happen with linkrepro scripts, at least
old ones.)
Differential Revision: https://reviews.llvm.org/D66466
llvm-svn: 369425
This is used by Wine for manually crafting export tables.
If the input object contains .edata sections, GNU ld references them
in the export directory instead of synthesizing an export table using
either export directives or the normal auto export mechanism. (AFAIK,
historically, way way back, GNU ld didn't support synthesizing the
export table - one was supposed to generate it using dlltool and link
it in instead.)
If faced with --out-implib and --output-def, GNU ld still populates
those output files with the same export info as it would have generated
otherwise, disregarding the input .edata. As this isn't an intended
usage combination, I'm not adding checks for that in tests.
Differential Revision: https://reviews.llvm.org/D65903
llvm-svn: 369358
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368936
These symbols actually point to the symbol's IAT entry, which
obviously is different from the symbol itself (which is imported
from a different module and doesn't exist in the current one).
Omitting this symbol helps gdb inspect automatically imported
symbols, see https://sourceware.org/bugzilla/show_bug.cgi?id=24574
for discussion on the matter.
Surprisingly, those extra symbols don't seem to be an issue for
gdb when the sources have been built with clang, only with gcc.
The actual logic in gdb that this depends on still is unknown, but
omitting these symbols from the symbol table is the right thing to
do in any case.
Differential Revision: https://reviews.llvm.org/D65727
llvm-svn: 367836
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
1. raw_ostream supports ANSI colors so that you can write messages to
the termina with colors. Previously, in order to change and reset
color, you had to call `changeColor` and `resetColor` functions,
respectively.
So, if you print out "error: " in red, for example, you had to do
something like this:
OS.changeColor(raw_ostream::RED);
OS << "error: ";
OS.resetColor();
With this patch, you can write the same code as follows:
OS << raw_ostream::RED << "error: " << raw_ostream::RESET;
2. Add a boolean flag to raw_ostream so that you can disable colored
output. If you disable colors, changeColor, operator<<(Color),
resetColor and other color-related functions have no effect.
Most LLVM tools automatically prints out messages using colors, and
you can disable it by passing a flag such as `--disable-colors`.
This new flag makes it easy to write code that works that way.
Differential Revision: https://reviews.llvm.org/D65564
llvm-svn: 367649
The Archive object created when loading an archive specified with
wholearchive got cleaned up immediately, when the owning std::unique_ptr
went out of scope, even if persisted StringRefs pointed to memory that
belonged to the archive, which no longer was mapped in memory.
This hasn't been an issue with regular (as opposed to thin) archives,
as references to the member objects has kept the mapping for the whole
archive file alive - but with thin archives, all such references point
to other files.
Add the std::unique_ptr to the arena allocator, to retain it as long
as necessary.
This fixes (the last issue raised in) PR42388.
Differential Revision: https://reviews.llvm.org/D65565
llvm-svn: 367599
Summary:
This allows reporting undefined symbols before LTO codegen is
run. Since LTO codegen can take a long time, this improves user
experience by avoiding that time spend if the link is going to
fail with undefined symbols anyway.
Fixes PR32400.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: mehdi_amini, steven_wu, dexonsmith, mstorsjo, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62434
llvm-svn: 367136
This ports r366573 from COFF to ELF.
There are now to toString(Archive::Symbol), one doing MSVC demangling
in COFF and one doing Itanium demangling in ELF, so rename these two
to toCOFFString() and to toELFString() to not get a duplicate symbol.
Nothing ever passes a raw Archive::Symbol to CHECK(), so these not
being part of the normal toString() machinery seems ok.
There are two code paths in the ELF linker that emits this type of
diagnostic:
1. The "normal" one in InputFiles.cpp. This is covered by the tweaked test.
2. An additional one that's only used for libcalls if there's at least
one bitcode in the link, and if the libcall symbol is lazy, and
lazily loaded from an archive (i.e. not from a lazy .o file).
(This code path was added in r339301.) Since all libcall names so far
are C symbols and never mangled, the change there is not observable
and hence not covered by tests.
Differential Revision: https://reviews.llvm.org/D65095
llvm-svn: 366836
Code built for mingw with -fdata-sections will store each TLS variable
in a comdat section, named .tls$$<varname>. Normal TLS variables are
stored in sections named .tls$ with a trailing dollar, which are
sorted after a starter marker (in a later linked object file) in a
section named ".tls" (with no dollar suffix), before an ending marker
in a section named ".tls$ZZZ".
The mingw comdat section suffix stripping introduced in SVN r363457
broke sorting of such tls sections, ending up sorting the stripped
.tls$$<varname> sections (stripped to ".tls") before the start marker
in the section named ".tls".
We could add exceptions to the section name suffix stripping for
.tls (and .CRT, where suffixes always should be honored), but the
more conservative option is probably the reverse; to only apply the
stripping for the normal sections where sorting shouldn't have any
effect.
Differential Revision: https://reviews.llvm.org/D65018
llvm-svn: 366780
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
Summary:
Fixes PR41828. Before this, LLD always emitted SafeSEH chunks and
defined __safe_se_handler_table & size. Now, /safeseh:no leaves those
undefined.
Additionally, we were checking for the safeseh @feat.00 flag in two
places: once to emit errors, and once during safeseh table construction.
The error was set up to be off by default, but safeseh is supposed to be
on by default. I combined the two checks, so now LLD emits an error if
an input object lacks @feat.00 and safeseh is enabled. This caused the
majority of 32-bit LLD tests to fail, since many test input object files
lack @feat.00 symbols. I explicitly added -safeseh:no to those tests to
preserve behavior.
Finally, LLD no longer sets IMAGE_DLL_CHARACTERISTICS_NO_SEH if any
input file wasn't compiled for safeseh.
Reviewers: mstorsjo, ruiu, thakis
Reviewed By: ruiu, thakis
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D63570
llvm-svn: 366238
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
E.g. for x86_64, previously each symbol's thunk was 87 bytes. Now
there's a 12 byte thunk per symbol, plus a shared 83 byte tail
function.
This is similar to what both MS link.exe and GNU tools do for
delay imports.
Differential Revision: https://reviews.llvm.org/D64288
llvm-svn: 365823
Summary:
Adds the following two options to lld-link:
-thinlto-prefix-replace: allows replacing a prefix in paths generated
for ThinLTO. This can be used to ensure index files and native object
files are stored in unique directories, allowing multiple distributed
ThinLTO links to proceed concurrently.
-thinlto-object-suffix-replace: allows replacing a suffix in object
file paths involved in ThinLTO. This allows minimized index files to
be used for the thin link while storing the paths to the full bitcode
files for subsequent steps (code generation and final linking).
Reviewers: ruiu, tejohnson, pcc, rnk
Subscribers: mehdi_amini, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D64542
llvm-svn: 365807
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
This patch does the same thing as r365595 to other subdirectories,
which completes the naming style change for the entire lld directory.
With this, the naming style conversion is complete for lld.
Differential Revision: https://reviews.llvm.org/D64473
llvm-svn: 365730
Since OPT_UNKNOWN args never have any values and consist only of
spelling (and are never aliased), this doesn't make any difference in
practice, but it's more consistent with Arg's guidance to use
getAsString() for diagnostics, and it matches what clang does.
Also tweak two tests to use an unknown option that contains '=' for
additional coverage while here. (The new tests pass fine with the old
code too though.)
llvm-svn: 365200
This fixes an 8-year-old regression. r105763 made it so that aliases
always refer to the unaliased option – but it missed the "joined" branch
of JoinedOrSeparate flags. (r162231 then made the Args classes
non-virtual, and r169344 moved them from clang to llvm.)
Back then, there was no JoinedOrSeparate flag that was an alias, so it
wasn't observable. Now /U in CLCompatOptions is a JoinedOrSeparate alias
in clang, and warn_slash_u_filename incorrectly used the aliased arg id
(using the unaliased one isn't really a regression since that warning
checks if the undefined macro contains slash or backslash and only then
emits the warning – and no valid use will pass "-Ufoo/bar" or similar).
Also, lld has many JoinedOrSeparate aliases, and due to this bug it had
to explicitly call `getUnaliasedOption()` in a bunch of places, even
though that shouldn't be necessary by design. After this fix in Option,
these calls really don't have an effect any more, so remove them.
No intended behavior change.
(I accidentally fixed this bug while working on PR29106 but then
wondered why the warn_slash_u_filename broke. When I figured it out, I
thought it would make sense to land this in a separate commit.)
Differential Revision: https://reviews.llvm.org/D64156
llvm-svn: 365186
- The code tried to pass false to split()'s KeepEmpty parameter, but
instead passed it to MaxSplit. As a result, it would never split on
commas. This has been broken since the flag was added in r278056.
- The code used getSpelling() for getting the argument's values, but
getSpelling() always returns the `/debugtype:` prefix without any
values. So if any /debugtype: flag was passed, it always resulted in
an "unknown option:" warning. (The warning code then used the correct
getValue() for printing the invalid option, so the warning looked
kind of like it made sense.) This regressed in r342894.
Slightly improve the test coverage of this feature (but since I don't
know what this flag actually does, there's still no test for the correct
semantics), and add a comment to getSpelling() explaining what it does.
llvm-svn: 365182
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
lld/coff already deduplicated undefined symbols on a TU level: It would
group all references to a symbol from a single TU. This makes it so that
references from all TUs to a single symbol are grouped together.
Since lld/coff almost did what I thought it did already, the patch is
much smaller than the elf version. The only not local change is that
getSymbolLocations() now returns a vector<string> instead of a string,
so that the undefined symbol reporting code can know how many references
to a symbol exist in a given TU.
Fixes PR42260 for lld/coff.
Differential Revision: https://reviews.llvm.org/D63646
llvm-svn: 364285
Some versions of the Visual C++ 2015 runtime have line tables with the
subsection kind of 0x800000F2. In cvinfo.h, 0x80000000 is documented to
be DEBUG_S_IGNORE. This appears to implement the intended behavior.
llvm-svn: 363724
This matches how it is done for .xdata and .pdata already.
On i386, the symbol name in the section name suffix does not contain
the extra underscore prefix.
This is one part of a fix for PR42217.
Differential Revision: https://reviews.llvm.org/D63350
llvm-svn: 363456
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
An unrecognized signature (magic) at the beginning of a debug section
should not be a fatal error; it only means that the debug information
is in a format that is not supported by LLD. This can be due to it
being in CodeView versions 3 or earlier. These can occur in old import
libraries from legacy SDKs.
The test case was verified to work with MS link.exe.
Patch by Vladimir Panteleev!
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D63177
llvm-svn: 363212
r363016 let lld-link and llvm-lib share the /machine: parsing code.
This lets llvm-cvtres share it as well.
Making llvm-cvtres depend on llvm-lib seemed a bit strange (it doesn't
need llvm-lib's dependencies on BinaryFormat and BitReader) and I
couldn't find a good place to put this code. Since it's just a few
lines, put it in lib/Object for now.
Differential Revision: https://reviews.llvm.org/D63120
llvm-svn: 363144
Users are exepcted to pass all .res files to the linker, which then
merges all the resource in all .res files into a tree structure and then
converts the final tree structure to a .obj file with .rsrc$01 and
.rsrc$02 sections and then links that.
If the user instead passes several .obj files containing such resources,
the correct thing to do would be to have custom code to merge the trees
in the resource sections instead of doing normal section merging -- but
link.exe rejects if multiple resource obj files are passed in with
LNK4078, so let lld-link do that too instead of silently writing broken
.rsrc sections in that case.
The only real way to run into this is if users manually convert .res
files to .obj files by running cvtres and then handing the resulting
.obj files to lld-link instead, which in practice likely never happens.
(lld-link is slightly stricter than link.exe now: If link.exe is passed
one .obj file created by cvtres, and a .res file, for some reason it
just emits a warning instead of an error and outputs strange looking
data. lld-link now errors out on mixed input like this.)
One way users could accidentally run into this is the following
scenario: If a .res file is passed to lib.exe, then lib.exe calls
cvtres.exe on the .res file before putting it in the output .lib.
(llvm-lib currently doesn't do this.)
link.exe's /wholearchive seems to only add obj files referenced from the
static library index, but lld-link current really adds all files in the
archive. So if lld-link /wholearchive is used with .lib files produced
by lib.exe and .res files were among the files handed to lib.exe, we
previously silently produced invalid output, but now we error out.
link.exe's /wholearchive semantics on the other hand mean that it
wouldn't load the resource object files from the .lib file at all.
Since this scenario is probably still an unlikely corner case,
the difference in behavior here seems fine -- and lld-link might have to
change to use link.exe's /wholearchive semantics in the future anyways.
Vaguely related to PR42180.
Differential Revision: https://reviews.llvm.org/D63109
llvm-svn: 363078
For lld, pass in Config->Timestamp (which is set based on lld's
/timestamp: and /Brepro flags). Since the writeWindowsResourceCOFF()
data is only used in-memory by LLD and the obj's timestamp isn't used
for anything in the output, this doesn't change behavior.
For llvm-cvtres, add an optional /timestamp: parameter, and use the
current behavior of calling time() if the parameter is not passed in.
This doesn't really change observable behavior (unless someone passes
/timestamp: to llvm-cvtres, which wasn't possible before), but it
removes the last unqualified call to time() from llvm/lib, which seems
like a good thing.
Differential Revision: https://reviews.llvm.org/D63116
llvm-svn: 363050
And share some code with lld-link.
While here, also add a FIXME about PR42180 and merge r360150 to llvm-lib.
Differential Revision: https://reviews.llvm.org/D63021
llvm-svn: 363016
Patch by Erik McClure with a modification to rebase to HEAD.
When calling `COFF::link()` with `CanExitEarly` set to `false`, the
function needs to clean up several global variable caches to ensure that
the next invocation of the function starts from a clean slate. The
`MergeChunk::Instances` cache is missing from this cleanup code, and as
a result will create nondeterministic memory access errors and sometimes
infinite loops due to invalid memory being referenced on the next call
to `COFF::link()`.
This fix simply clears `MergeChunk::Instances` before exiting the function.
An additional review of the COFF library was made to try and find any
other missing global caches, but I was unable to find any other than
`MergeChunk`. Someone more familiar with the global variables might want
to do their own check.
This fix was made to support inNative
<https://github.com/innative-sdk/innative>'s `.wast` script compiler,
which must build multiple incremental builds. It relies on statically
linking LLD because the entire compiler must be a single statically
embeddable library, thus preventing it from being able to call LLD as a
new process.
Differential Revision: https://reviews.llvm.org/D63042
llvm-svn: 362930
This works like /include, but is not fatal if the requested symbol
wasn't found. This allows implementing the GNU ld option -u.
Differential Revision: https://reviews.llvm.org/D62976
llvm-svn: 362881
Summary:
When handling exports from the command line or from .def files, the
linker does a "fuzzy" string lookup to allow finding mangled symbols.
However, when the symbol is re-exported under a new name, the linker has
to transfer the decorations from the exported symbol over to the new
name. This is implemented by taking the mangled symbol that was found in
the object and replacing the original symbol name with the export name.
Before this patch, LLD implemented the fuzzy search by adding an
undefined symbol with the unmangled name, and then during symbol
resolution, checking if similar mangled symbols had been added after the
last round of symbol resolution. If so, LLD makes the original symbol a
weak alias of the mangled symbol. Later, to get the original symbol
name, LLD would look through the weak alias and forward it on to the
import library writer, which copies the symbol decorations. This
approach doesn't work when bar is itself a weak alias, as is the case in
asan. It's especially bad when the aliasee of bar contains the string
"bar", consider "bar_default". In this case, we would end up exporting
the symbol "foo_default" when we should've exported just "foo".
To fix this, don't look through weak aliases to find the mangled name.
Save the mangled name earlier during fuzzy symbol lookup.
Fixes PR42074
Reviewers: mstorsjo, ruiu
Subscribers: thakis, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62984
llvm-svn: 362849
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
Summary:
- Fixes inline call frame line table display in windbg.
- Improve llvm-pdbutil to dump extra file ids.
- Warn on unknown subsections so we don't have this kind of bug in the
future.
Reviewers: inglorion, akhuang, aganea
Subscribers: eraman, zturner, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D62701
llvm-svn: 362429
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
Shaves another pointer off of SectionChunk, reducing the size from 96 to
88 bytes, down from 144 before I started working on this. Combined with
D62356, this reduced peak memory usage when linking chrome_child.dll
from 713MB to 675MB, or 5%.
Create NonSectionChunk to provide virtual dispatch to the rest of the
chunk types.
Reviewers: ruiu, aganea
Differential Revision: https://reviews.llvm.org/D62362
llvm-svn: 361667
Shaves another 8 bytes off of SectionChunk, the most commonly allocated
type in LLD.
These indices are only valid after we've assigned chunks to output
sections and removed empty sections, so do that in a new pass.
Reviewers: ruiu, aganea
Differential Revision: https://reviews.llvm.org/D62356
llvm-svn: 361657
Patch by Stefan Schmidt.
This adds the /filealign parameter to lld, which allows to specify the
section alignment in the output file (as it does on Microsoft's
link.exe).
This is required to be able to load dynamically linked libraries on the
original Xbox, where the debugger monitor expects the section alignment
in the file to be the same as in memory.
llvm-svn: 361634
This only needs to be done for MergeChunks, so just do that in a
separate pass in the Writer.
This is one small step towards eliminating the vtable in Chunk.
llvm-svn: 361573
The KeepUnique bit is used during ICF, which only operates on
SectionChunks, so only SectionChunks need it. This frees up a byte in
Chunk, which I plan to use in a follow-up change.
llvm-svn: 361549
OptTable treats arguments starting with / that aren't a known option
as filenames. This means lld-link's and clang-cl's typo correction for
unknown flags didn't do spell checking for misspelled options that start
with /.
I first tried changing OptTable, but that got pretty messy, see PR41787
comments 2 and 3.
Instead, let lld-link's and clang's (including clang-cl's) "file not
found" diagnostic check if a non-existent file looks like it could be a
mis-spelled option, and if so add a "did you mean" suggestion to the
"file not found" diagnostic.
While here, make formatting of a few diagnostics a bit more
self-consistent.
Fixes PR41787.
Differential Revision: https://reviews.llvm.org/D62276
llvm-svn: 361518
The previous patch lost the call to PowerOf2Ceil, which causes LLD to
crash when handling common symbols with a non-power-of-2 size. I tweaked
the existing common.test to make the bsspad16 common symbol be 15 bytes
to add coverage for this case.
llvm-svn: 361426
Summary:
Valid section or chunk alignments are powers of 2 in the range [1,
8192]. These can be stored more canonically in log2 form to free up some
bits in Chunk. Combined with D61696, SectionChunk gets 8 bytes smaller.
Reviewers: ruiu, aganea
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61698
llvm-svn: 361206
Change
std::error_code getSectionContents(DataRefImpl, StringRef &) const;
to
Expected<ArrayRef<uint8_t>> getSectionContents(DataRefImpl) const;
Many object formats use ArrayRef<uint8_t> as the underlying type, which
is generally better than StringRef to represent binary data, so change
the type to decrease the number of type conversions.
Reviewed By: ruiu, sbc100
Differential Revision: https://reviews.llvm.org/D61781
llvm-svn: 360648
Summary:
Prior to this change, every implementation of writeTo would add
OutputSectionOff to the output section buffer start before writing data.
Instead, do this math in the caller, so that it can be written once
instead of many times.
The output section offset is always equivalent to the difference between
the chunk RVA and the output section RVA, so we can replace the one
remaining usage of OutputSectionOff with that subtraction.
This doesn't change the size of SectionChunk because of alignment
requirements, but I will rearrange the fields in a follow-up change to
accomplish that.
Reviewers: ruiu, aganea
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61696
llvm-svn: 360376
Summary:
When using lld-link to build static libraries containing object files
with module assembly, the program would crash with "Assertion `T &&
T->hasMCAsmParser()' failed". This change causes the code in lld-link
that initialized Targets, TargetInfos, and AsmParsers (which already
existed) to be run before entering the lib building path (which needs
it). This avoids the error (and is what llvm-lib and llvm-ar do, too).
Fixes PR41803.
Reviewers: ruiu, rnk, hans
Reviewed By: ruiu
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D61699
llvm-svn: 360295
link.exe seems to allow `/?foo` and `-?foo` in addition to `/foo` and `-foo`.
Since lld-link already supports the `-?foo` spelling, support `/?foo` as well.
Differential Revision: https://reviews.llvm.org/D61375
llvm-svn: 360150
For lld-link, unknown '/'-style flags are treated as filenames on POSIX
systems, so only '-'-style flags get typo correction for now. This
matches clang-cl.
PR37006.
Differential Revision: https://reviews.llvm.org/D61443
llvm-svn: 360145
SectionChunk is one of the most frequently allocated data structures in
LLD, since there are about four per function when optimizations and
debug info are enabled (.text, .pdata, .xdata, .debug$S).
A PE COFF file cannot be larger than 2GB, so there is an inherent limit
on the length of the section name and the number of relocations.
Decompose the ArrayRef and StringRef into pointer and size, and put them
back together in the accessors for section name and relocation list.
I plan to gather complete performance numbers later by padding
SectionChunk with dead data and measuring performance after all the size
optimizations are done.
llvm-svn: 359923
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
Summary:
It currently receives an output parameter and returns
std::error_code. Expected<StringRef> fits for this purpose perfectly.
Differential Revision: https://reviews.llvm.org/D61421
llvm-svn: 359774
Reduces the error message from:
lld-link: error: failed to parse .res file: duplicate resource: type STRINGTABLE (ID 6)/name ID 3/language 1033, in test1.res and in test2.res
To:
lld-link: error: duplicate resource: type STRINGTABLE (ID 6)/name ID 3/language 1033, in test1.res and in test2.res
Make sure every error message emitted by cvtres contains the name of at
least one ".res" file, so that removing the "failed to parse .res file"
string doesn't lose information.
Differential Revision: https://reviews.llvm.org/D61388
llvm-svn: 359749
r191276 added this to old LLD, but it never made it to new LLD -- except
that the flag was in Options.td, so it was silently ignored. I figured
it should be easy to implement, so I did that instead of removing the
flags from Options.td.
I then discovered that link.exe also supports comma-separated lists of
'cd' and 'net', which made the parsing code a bit annoying.
The Alias technique in Options.td is to get nice help output.
Differential Revision: https://reviews.llvm.org/D61067
llvm-svn: 359192
The following options: /pdb, /out or /implib now emit in the repro.tar/response.txt only a filename stripped from its path, to avoid non-existent paths on the reproducer's machine.
Differential Revision: https://reviews.llvm.org/D59530
llvm-svn: 358980
Make some small adjustment while touching the code: make parameters
const, use less_first(), etc.
Differential Revision: https://reviews.llvm.org/D60989
llvm-svn: 358943
Summary:
This assumes all symbols are <4GB long, so we can store them as a 32-bit
integer. This reorders the fields so the length appears first, packing
with the other bitfield data in the base Symbol object.
This saved 70MB / 3.60% of heap allocations when linking
browser_tests.exe with no PDB. It's not much as a percentage, but worth
doing. I didn't do performance measurements, I don't think it will be
measurable in time.
Reviewers: ruiu, inglorion, amccarth, aganea
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60297
llvm-svn: 358794
Summary:
Archives can contain multiple members with the same name. This would
cause ThinLTO links to fail ("Expected at most one ThinLTO module per
bitcode file"). This change implements the same strategy we use in
the ELF linker: make the offset in the archive part of the module
name so that names are unique.
Reviewers: pcc, mehdi_amini, ruiu
Reviewed By: ruiu
Subscribers: eraman, steven_wu, dexonsmith, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60549
llvm-svn: 358440
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:
Now CVType and CVSymbol are effectively type-safe wrappers around
ArrayRef<uint8_t>. Make the kind() accessor load it from the
RecordPrefix, which is the same for types and symbols.
Reviewers: zturner, aganea
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60018
llvm-svn: 357658
Summary:
Reorder the fields in both to use padding more efficiently, and add more
comments on the purpose of the fields.
Replace `std::vector<SectionChunk*> AssociativeChildren` with a
singly-linked list. This avoids the separate vector allocation to list
associative children, and shrinks the 3 pointers used for the typically
empty vector down to 1.
In the end, this reduces the sum of heap allocations used to link
browser_tests.exe with NO PDB by 13.10%, going from 2,248,728 KB to
1,954,071 KB of heap. These numbers exclude memory mapped files, which
are of course a significant factor in LLD's memory usage.
Reviewers: ruiu, mstorsjo, aganea
Subscribers: jdoerfert, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59797
llvm-svn: 357535
Introduce a new TypeMerger class, out of some type-merge-specific structures from PDB.cpp
No changes intended / this is only moving code around.
This patch is step 3. in "Proposed commit strategy" in D59226
Differential Revision: https://reviews.llvm.org/D60070
llvm-svn: 357525
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
Generate import modules for each imported DLL, along with its symbol stream.
Also create COFF groups in the * Linker * module, one for each PartialSection (input, unmerged sections)
Currently COFF groups are disabled for MINGW because it significantly increases PDB sizes. We could enable that later with an option.
The overall objective for this change is to support code hot patching tools. Such tools need to know the import libraries used, from the PDB alone.
Differential Revision: https://reviews.llvm.org/D54802
llvm-svn: 357308
Summary:
This avoids allocating O(#relocs) of intermediate data for each section
when range extension thunks aren't needed for that section. This also
removes a std::vector from SectionChunk, which further reduces its size.
Instead, this change adds the range extension thunk symbols to the
object files that contain sections that need extension thunks. By adding
them to the symbol table of the parent object, that means they now have
a symbol table index. Then we can then modify the original relocation,
after copying it to read-write memory, to use the new symbol table
index.
This makes linking browser_tests.exe with no PDB 10.46% faster, moving
it from 11.364s to 10.288s averaged over five runs.
Reviewers: mstorsjo, ruiu
Subscribers: aganea, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D59902
llvm-svn: 357200
Take module DBI creation out of PDBLinker::addObjFile() into its own function.
This is groundwork towards parallelizable type merging, as proposed in D59226.
Differential Revision: https://reviews.llvm.org/D59261
llvm-svn: 356815
Before, empty debug streams were written as 8 bytes (4 bytes signature + 4 bytes for the GlobalRefs count).
With this patch, unused empty streams aren't emitted anymore. Modules now encode 65535 as an 'unused stream' value, by convention.
Also fix the * Linker * contrib section which wasn't correctly emitted previously.
Differential Revision: https://reviews.llvm.org/D59502
llvm-svn: 356395
/summary prints information about the data (OBJ/LIB/PDB) processed by LLD. The goal is have an estimate about the inputs and outputs, to better understand where the timings go.
Differential Revision: https://reviews.llvm.org/D58599
llvm-svn: 356188
This makes lld-link's output a bit more concise. Since most developers can't
read mangled names, this should make the output a bit easier to understand as
well. It also makes lld-link's output consistent with ld.lld's output.
(link.exe prints both demangled and mangled names; lld-link used to match
link.exe output but now no longer does.)
For people working on toolchains, add a `/demangle:no` flag that makes lld-link
print the mangled name instead of the demangled name. (If desired, people could
pipe that through `demumble -b` to get the old behavior of both demangled and
mangled output.)
Differential Revision: https://reviews.llvm.org/D58132
llvm-svn: 355878
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
Summary:
We translate @llvm.used to COFF by generating /include directives
in the .drectve section. However, in LTO links, this happens after
directives have already been processed, so the new directives do
not take effect. This change marks @llvm.used symbols as GCRoots
so that they are preserved as intended.
Fixes PR40733.
Reviewers: rnk, pcc, ruiu
Reviewed By: ruiu
Subscribers: mehdi_amini, steven_wu, dexonsmith, dang, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D58255
llvm-svn: 354410
This is a private undocumented option, intended to be used by
the MinGW driver frontend.
Also restructure the condition to put if (Config->MinGW) first.
This changes the behaviour for the tautological combination of
-export-all-symbols without -lldmingw.
Differential Revision: https://reviews.llvm.org/D58380
llvm-svn: 354386
Turns out nobody understands what "conflicting comdat type" is supposed to
mean, so just emit a regular "duplicate symbol" error and move the comdat
selection information into /verbose output.
This also fixes a problem where the error output would depend on the order of
.obj files passed. Before this patch:
- If passed `one_only.obj discard.obj`, lld-link would only err "conflicting
comdat type"
- If passed `discard.obj one_only.obj`, lld-link would err "conflicting comdat
type" and then "duplicate symbol"
Now lld-link only errs "duplicate symbol" in both cases.
I considered adding a "Detail" parameter to reportDuplicate() that's printed in
parens at the end of the "duplicate symbol" diag if present, and then put the
comdat selection mismatch details there, but since users don't know what it's
supposed to mean decided against it. I also considered special-casing the
Detail message for one_only/discard mismatches, which in practice means
"function defined as inline in TU 1 but as out-of-line in TU 2", but I wasn't
sure how useful it is so I omitted that too.
Differential Revision: https://reviews.llvm.org/D58180
llvm-svn: 354006
Summary:
The message "could not get the buffer for the member defining symbol"
now also contains the name of the archive and the name of the archive
member that we tried to open.
Reviewers: ruiu
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D57974
llvm-svn: 353572
In a previous patch, I made changes so that PDBs which were
generated on non-Windows platforms contained sensical paths
for the host. While this is an esoteric use case, we need
it to be supported for certain cross compilation scenarios
especially with LLDB, which can debug things on non-Windows
platforms.
However, this regressed a case where you specify /PDBSOURCEPATH
and use a windows-style path. Previously, we would still remove
dots and canonicalize slashes to backslashes, but since my
change intentionally tried to support non-backslash paths, this
was broken.
This patch fixes the situation by trying to guess which path
style the user is specifying when /PDBSOURCEPATH is passed.
It is intentionally conservative, erring on the side of a
Windows path style unless absolutely certain. All dots are
removed and slashes canonicalized to whatever the deduced
path style is after appending the file path to the /PDBSOURCEPATH
argument.
Differential Revision: https://reviews.llvm.org/D57769
llvm-svn: 353250
For MinGW, unique partial sections are much more common, e.g.
comdat functions get sections named e.g. text$symbol.
A moderate sized example of this contains over 200K Chunks
which create 174K unique PartialSections. Prior to SVN r352928
(D57574), linking this took around 1,5 seconds for me, while
it afterwards takes around 13 minutes. After this patch, the
linking time is back to what it was before.
The std::find_if in findPartialSection will do a linear scan of
the whole container until a match is found. To use something like
binary_search or the std::set container's own methods, we'd need
to already have a PartialSection*.
Reinstate a proper map instead of having a set with a custom sorting
comparator.
Differential Revision: https://reviews.llvm.org/D57666
llvm-svn: 353146
On ARM64, this is normally necessary only after a module exceeds
128 MB in size (while the limit for thumb is 16 MB). For conditional
branches, the range limit is only 1 MB though (the same as for thumb),
and for the tbz instruction, the range is only 32 KB, which allows for
a test much smaller than the full 128 MB.
This fixes PR40467.
Differential Revision: https://reviews.llvm.org/D57575
llvm-svn: 352929
When writing a PDB, the OutputSection of all chunks need to be set.
The thunks are added directly to OutputSection after the normal
machinery that sets it for all other chunks.
This fixes part of PR40467.
Differential Revision: https://reviews.llvm.org/D57574
llvm-svn: 352928
cl.exe and clang-cl.exe put vftables in a 'discard' comdat when building with
RTTI disabled (/GR-) but in a 'largest' comdat when building with RTTI enabled.
To be able to link /GR- code with /GR code, lld-link needs to accept comdats
that have this type of comdat selection conflict.
For example, static libraries in the Visual Studio standard library are built
with /GR, and without this it's impossible to build client code with /GR- and
still link to the standard library.
link.exe also accepts merging 'discard' with 'largest', and it accepts merging
'largest' with any other selection type. lld-link is still a bit stricter since
it only allows merging 'largest' with 'discard' for symmetry.
Differential Revision: https://reviews.llvm.org/D57515
llvm-svn: 352765
Previously we were never setting this which means it was always being
set to Default (-O2/-Os).
Differential Revision: https://reviews.llvm.org/D57422
llvm-svn: 352667
LLD used to handle comdats as if the selection field was always set to
IMAGE_COMDAT_SELECT_ANY. This means for obj files produced by `cl /Gy`, LLD
would never report a duplicate symbol error.
This change:
- adds validation for the Selection field (should make no difference in
practice for compiler-generated obj inputs)
- rejects comdats that have different Selection fields in different obj files
(likewise). This is a bit more strict but also more self-consistent thank
link.exe (see comment in code)
- implements handling for all the selection kinds
In practice, compilers only generate comdats with
IMAGE_COMDAT_SELECT_NODUPLICATES (LLD now produces duplicate symbol errors for
these), IMAGE_COMDAT_SELECT_ANY (no behavior change), and
IMAGE_COMDAT_SELECT_LARGEST (for RTTI data; here LLD should no longer create
broken executables when linking some TUs with RTTI enabled and some with it
disabled – but see below).
The implementation of `IMAGE_COMDAT_SELECT_LARGEST` is incomplete: If one
SELECT_LARGEST comdat replaces an earlier one, the comdat symbol is replaced
correctly, but the old section stays loaded and if /opt:ref is disabled (via
/opt:noref or /debug) it's still written to the output. That's not ideal, but
better than the current treatment of just picking any one of those comdats. I
hope to fix this better later.
Fixes most of PR40094.
Differential Revision: https://reviews.llvm.org/D57324
llvm-svn: 352590
References between associated comdats are invalid per COFF spec, but the newest
Windows SDK contains obj files that have these references
(https://bugs.chromium.org/p/chromium/issues/detail?id=925943#c13). So add back
support for them and add tests for them. The old code handled them fine.
This makes lld-link match the behavior of newer link.exe versions as far as I
can tell. (The behavior before this change matched the behavior of older
link.exe versions.)
This mostly reverts r352254.
Differential Revision: https://reviews.llvm.org/D57387
llvm-svn: 352508
Many different sections can have the same name, so include the indices of the
sections mentioned in the diagnostic too.
I'm debugging something I can't repro locally, maybe this will help.
llvm-svn: 352428
Persist (input) sections that make up an OutputSection. This is a supporting patch for the upcoming D54802.
Differential Revision: https://reviews.llvm.org/D55293
llvm-svn: 352336
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
Martin Storsjö