Adds support for ARM64EC, which should use the same search paths as
ARM64.
It's similar to #87370 and #87495. The test is based on the existing x86
test. Generally ARM64EC libraries are shipped together with native ARM64
libraries (using ECSYMBOLS section mechanism).
getMachineArchType uses Triple::thumb, while the existing
implementation uses Triple::arm. It's ultimately passed to
MSVCPaths.cpp functions, so modify them to accept both forms.
#78772 added similar support for .def file parser and import library
writer. This PR adds missing bits in LLD to propagate EXPORTAS name and
allow it in `/export` parser. This is syntax is used by MSVC for ARM64EC
`__declspec(dllexport)` handling.
Following the commit of #83972 which added COFF support for SPGO, this
patch ports the support of the option -lto-sample-profile that was only
available in the ELF variant of LLD to the COFF variant to enable
running the SPGO passes in the LTO/thinLTO pipelines.
This can be used to create import libraries that contain both ARM64EC
and native exports. The implementation follows observed MSVC lib.exe
behaviour. It's ignored on targets other than ARM64EC.
The SOURCE_DATE_EPOCH environment variable can be set in order to get
reproducible build.
When linking PE/COFF modules with LLD, the timestamp field is set to the
current time, unless either the /timestamp: or /Brepro option is set. If
neither of them is set, check the SOURCE_DATE_EPOCH variable, before
resorting to using the actual current date and time.
See https://reproducible-builds.org/docs/source-date-epoch/ for reference
on the use of this variable.
The main reason for adding the toolchain paths early was to prefer
libraries from the toolchain over ones from MSVC (primarily for
compiler-rt builtins). But if the user specifies a directory explicitly
with the -libpath: option, that should be preferred over the built-in
default paths.
This fixes an issue raised at
https://discourse.llvm.org/t/lld-prefers-system-llvm-libraries-to-user-provided-ones-on-windows/76148.
Most option handling is like it was before; the last /debug: option
takes effect.
However, the options /debug:dwarf or /debug:symtab don't reset all flags
into the specific behaviour they chose before - e.g. if an earlier
option enables writing a PDB, a later /debug:dwarf or /debug:symtab
doesn't disable that. This allows combining these options with options
for controlling PDB writing, for finetuning what is done.
Don't treat the options as unique enum items, but more as flags that can
be composed, like the /opt: options.
This still only processes the last option on the command line though, so
the behaviour should still remain exactly as it was, in all corner
cases.
This shouldn't have any user visible effect, but makes the logic within
the linker implementation more explicit.
Note how DWARF debug info sections were retained even if enabling a link
with PDB info only; that behaviour is preserved.
After #71433, lld-link is able to always generate build id even when PDB
is not generated.
This adds the `__buildid` symbol to points to the start of 16 bytes guid
(which is after `RSDS`) and allows profile runtime to access it and dump
it to raw profile.
[RFC](https://discourse.llvm.org/t/rfc-add-build-id-flag-to-lld-link/74661)
Before, lld-link only generate the debug directory containing guid when
generating PDB with the hash of PDB content.
With this change, lld-link can generate the debug directory when only
`/build-id` is given:
1. If generating PDB, `/build-id` is ignored. Same behaviour as before.
2. Not generating PDB, using hash of the binary.
- Not under MinGW, the debug directory is still in `.rdata` section.
- Under MinGW, place the debug directory into new `.buildid` section.
ARM64EC needs to handle both ARM and x86_64 exception tables. This is
achieved by separating their chunks and sorting them separately.
EXCEPTION_TABLE directory references x86_64 variant, while ARM variant
is exposed using CHPE metadata, which references
__arm64x_extra_rfe_table and __arm64x_extra_rfe_table_size symbols.
This is necessary if the object file containing _tls_used is built with
-fdata-sections; if this symbol is present, lld is going to include
references to it in the PE header, in the TLS_TABLE data directory.
Therefore, treat the symbol as a GC root, i.e. retain it (and whatever
other symbols the section chunk references) when doing doing GC
(/opt:ref), if the symbol is present.
In mingw mode, all linker paths are passed explicitly to the linker
by the compiler driver. Don't try to implicitly add linker paths
from the LIB environment variable or by detecting an MSVC
installation directory.
If the /winsysroot command line parameter is explicitly passed to
lld-link while /lldmingw is specified, it could be considered reasonable
to actually include those paths. However, modifying the code to
handle only the /winsysroot case but not the other ones, when the
mingw mode has been enabled, seems like much more code complexity
for a mostly hypothetical case.
Add a test for this when case when using LIB. (The code paths for
trying to detect an MSVC installation aren't really regression tested.)
Also fix an issue in the existing test for "Check that when /winsysroot
is specified, %LIB% is ignored.", where the LIB variable pointed
to a nonexistent directory, so the test would pass even if /winsysroot
wouldn't be specified.
Reland this after https://github.com/llvm/llvm-project/pull/68077 and
https://github.com/llvm/llvm-project/pull/69781 - the compiler-rt test
that used -lldmingw in MSVC environments has been updated to use a more
specific option.
Differential Revision: https://reviews.llvm.org/D144084
The MinGW mode (enabled with the flag -lldmingw) does allow duplicate
weak symbols. A test in
compiler-rt/test/profile/Windows/coverage-weak-lld.cpp does currently
enable the -lldmingw flag in an MSVC context, in order to deal with
duplicate weak symbols.
Add a new, separate, lld specific flag for enabling this. In MinGW mode,
this is enabled by default, otherwise it is disabled.
This allows making the MinGW mode more restrictive in adding libpaths
from the surrounding environment; in MinGW mode, all libpaths are passed
explicitly by the compiler driver to the linker, which is attempted in
https://reviews.llvm.org/D144084.
Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces support::{big,little,native} with
llvm::endianness::{big,little,native}.
This adds support for generating Chrome-tracing .json profile traces in
the LLD COFF driver.
Also add the necessary time scopes, so that the profile trace shows in
great detail which tasks are executed.
As an example, this is what we see when linking a Unreal Engine
executable:
Before af744f0b84, the first entry
among the search paths was the empty string, indicating searching
in (or starting from) the current directory. After
af744f0b84, the toolchain/clang
specific lib directories were added at the head of the search path.
This would cause lookups of literal file names or relative paths
to match paths in the toolchain, if there are coincidental files
with similar names there, even if they would be find in the current
directory as well.
Change addClangLibSearchPaths to append to the list like all other
operations on searchPaths - but move the invocation of the
function to the right place in the sequence.
This fixes#67779.
We want lld-link to automatically find compiler-rt's and
libc++ when it's in the same directory as the rest of the
toolchain. This is because on Windows linking isn't done
via the clang driver - but instead invoked directly.
This prepends: <llvm>/lib <llvm>/lib/clang/XX/lib and
<llvm>/lib/clang/XX/lib/windows automatically to the library
search paths.
Related to #63827
Differential Revision: https://reviews.llvm.org/D151188
This patch is spun out of https://reviews.llvm.org/D151188
and makes it possible for lld-link to find libraries with
relative paths. This will be used later to implement the
changes to autolinking runtimes explained in #63827
Differential Revision: https://reviews.llvm.org/D155268
While working on adding more implicit search paths to the
lld COFF driver, it was helpful to have a way to print all
the search paths, both for debugging and for testing without
having to create very complicated test cases.
This is a simple arg that just prints the search paths and exits.
Related to the efforts in #63827
Differential Revision: https://reviews.llvm.org/D155047
This patch added /dwodir to lld/COFF which is equivalent to lld/ELF
option -plugin-opt=dwo_dir=. This option tells LTO backend to create
dwo directory and files and all dwo files will be in it. Otherwise all
dwarf sections will be embeded into image even if -gsplit-dwarf is
specified when using LTO.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D154070
MSVC link.exe allows overriding exports on the cmd-line with exports seen in OBJ directives. The typical case is what is described in #62329.
Before this patch, trying to override an export with `/export` or `/def` would generate a duplicate warning. This patches tries to replicate the MSVC behavior. A second override on the cmd-line would still generate the warning.
There's still a case which we don't cover: MSVC link.exe is able to demangle an exported OBJ directive function, and match it with a unmangled export function in a .def file. In the meanwhile, one can use the mangled export in the .def to cover that case.
This fixes#62329
Differential revision: https://reviews.llvm.org/D149611
Follow up to D151815.
Or else we properly handle the first instance of a file, then error out on the second instance of the same file.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D152198
With /winsysroot and without /machine, we don't know which paths to add to the search paths.
We do autodetect machine type and add winsysroot search paths in SymbolTable::addFile(), but that happens after all input files are opened. So in the loop where we read files, if we fail to open a file we can retry with the winsysroot search path potentially added by reading a previous file. This will fail if we try to open something in the winsysroot before reading a file that can give us the architecture, but shrug.
Fixes#54409
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D151815
This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view.
Note that the llvm/ directory has migrated in commit
6c3ea866e9.
I'll post a separate patch to deprecate
StringRef::{starts,ends}with_insensitive.
Differential Revision: https://reviews.llvm.org/D150506
MSVC link.exe added this flag and MS STL started using this flag in
.drectve [1] when compiling with Clang with asan enabled, as reported
on https://github.com/llvm/llvm-project/issues/56300. This causes issues
with lld-link because it rejects any unknown flags in .drective sections.
As dc07867dc9 noted that, when using Clang
as the driver it explicitly passes the proper asan libraries. Therefore
it should be acceptable to ignore this flag in lld-link to at least
unbreak building with clang-cl and linking with lld-link.
[1]: faaf094ee1/stl/inc/__msvc_sanitizer_annotate_container.hpp (L35)
Differential Revision: https://reviews.llvm.org/D149023
