This reverts commit 4e3b89483a, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
All command-line tools using `llvm::opt` create an enum of option IDs and a table of `OptTable::Info` object. Most of the tools use the same ID (`OPT_##ID`), kind (`Option::KIND##Class`), group ID (`OPT_##GROUP`) and alias ID (`OPT_##ALIAS`). This patch extracts that common code into canonical macros. This results in fewer changes when tweaking the `OPTION` macros emitted by the TableGen backend.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157028
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
In 64 bit mode, any references to symbols that might end up autoimported
must be made via full 64 bit pointers (usually in .refptr stubs
generated by the compiler).
If referenced via e.g. a 32 bit rip relative offset, it might work
as long as DLLs are loaded close together in the 64 bit address
space, but will fail surprisingly later if they happen to be loaded
further apart. Any cases of that happening is usually a toolchain
error, and the sooner we can warn about it, the easier it is to diagnose.
Differential Revision: https://reviews.llvm.org/D154777
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
In preparation for removing the `#include "llvm/ADT/StringExtras.h"`
from the header to source file of `llvm/Support/Error.h`, first add in
all the missing includes that were previously included transitively
through this header.
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
As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using `llvm::demangle`. Add a
release note.
Differential Revision: https://reviews.llvm.org/D149104
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 adds very minimal support for ARM64EC/ARM64X targets,
just enough for interesting test cases. Next patches in the
series extend llvm-objdump and llvm-readobj to provide
better tests. Those will also be useful for testing further
ARM64EC LLD support.
Differential Revision: https://reviews.llvm.org/D149086
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
MS link accepts *.obj with ehcont bit set only. LLD should match this
behavoir too.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D150508
This reverts commit c117c2c8ba.
itaniumDemangle calls std::strlen with the results of
std::string_view::data() which may not be NUL-terminated. This causes
lld/test/wasm/why-extract.s to fail when "expensive checks" are enabled
via -DLLVM_ENABLE_EXPENSIVE_CHECKS=ON. See D149675 for further
discussion. Back this out until the individual demanglers are converted
to use std::string_view.
As suggested by @erichkeane in
https://reviews.llvm.org/D141451#inline-1429549
There's potential for a lot more cleanups around these APIs. This is
just a start.
Callers need to be more careful about sub-expressions producing strings
that don't outlast the expression using ``llvm::demangle``. Add a
release note.
Reviewed By: MaskRay, #lld-macho
Differential Revision: https://reviews.llvm.org/D149104
When running the LLD test suite on a big-endian host, the
COFF/pdb-framedata.yaml test case currently fails.
As it turns out, this is because code in DebugSHandler::finish
intended to relocate RvaStart entries of FDO records does not
work correctly when compiled for a big-endian host.
Fixed by always reading file data in little-endian mode.
Reviewed By: aganea
Differential Revision: https://reviews.llvm.org/D149268
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
Currently, the --thinlto-prefix-replace="oldpath;newpath" option is used during
distributed ThinLTO thin links to specify the mapping of the input bitcode object
files' directory tree (oldpath) to the directory tree (newpath) used for both:
1) the output files of the thin link itself (the .thinlto.bc index files and the
optional .imports files)
2) the specified object file paths written to the response file given in the
--thinlto-index-only=${response} option, which is used by the final native
link and must match the paths of the native object files that will be
produced by ThinLTO backend compiles.
This patch expands the --thinlto-prefix-replace option to allow a separate directory
tree mapping to be specified for the object file paths written to the response file
(number 2 above). This is important to support builds and build systems where the
same output directory may not be written by multiple build actions (e.g. the thin link
and the ThinLTO backend compiles).
The new format is: --thinlto-prefix-replace="origpath;outpath[;objpath]"
This replaces the origpath directory tree of the thin link input files with
outpath when writing the thin link index and imports outputs (number 1
above). If objpath is specified it replaces origpath of the input files with
objpath when writing the response file (number 2 above), otherwise it
falls back to the old behavior of using outpath for this as well.
Reviewed By: tejohnson, MaskRay
Differential Revision: https://reviews.llvm.org/D144596
It doesn't make sense on ARM and using default 0 fill is compatible
with MSVC.
(It's more noticeable ARM64EC targets, where additional padding mixed
with alignment is used for entry thunk association, so there are more
gaps).
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D145962
Extend the logic for the WinSDK and UCRT handling to prefer a user
specified version of the VisualC++ tools and Windows SDK. This allows
us to now perform the regular search for the installation but select the
exact version of the SDK or VC++ tools to override the latest version.
Similar to the other flags controlling this behaviour, if the user
specifies a value, we will not perform validation on the input and will
attempt to prefer that, particularly in the case of VisualC++ tools
where no fallback occurs.
Reviewed by: hans
Differential Revision: https://reviews.llvm.org/D145517
When linking a shared library with Flang on MinGW, the functions from the
Flang runtime are exported from the shared library. When trying to link an
executable to that library using Flang, the linker errors out because the
functions from the runtime conflict with the functions exported from the
shared library.
Add the Flang runtime libraries to the list of libraries for which no
symbols are exported.
Reapplying the patch with the git author name corrected.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D145389
This reverts commit 04fc67bf08.
The patch was applied with the wrong git author name (forgot to
amend in the right user name after applying the patch); I'll
reapply it with the right author name.
When linking a shared library with Flang on MinGW, the functions from the
Flang runtime are exported from the shared library. When trying to link an
executable to that library using Flang, the linker errors out because the
functions from the runtime conflict with the functions exported from the
shared library.
Add the Flang runtime libraries to the list of libraries for which no
symbols are exported.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D145389
We hit this in Chromium builds where the PDB file was just under 4GB,
but the stream directory was actually too large to be correctly
represented.
llvm-pdbutil would error about this in llvm::msf::validateSuperBlock,
but lld should not write such PDB files in the first place.
Differential revision: https://reviews.llvm.org/D144385
This reverts commit 389bfbd66d.
This commit broke the compiler-rt/test/profile/Windows/coverage-weak-lld.cpp
testcase. This testcase builds and links in an MSVC environment,
but explicitly passes -lldmingw to the linker, to opt in to
certain mingw-style behaviours regarding weak symbols, since
effb87dfa8. This patch broke that
test, which now errored out with these errors:
lld-link: error: could not open 'libuuid.a': no such file or directory
lld-link: error: could not open 'libLIBCMT.a': no such file or directory
lld-link: error: could not open 'libOLDNAMES.a': no such file or directory
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.
Differential Revision: https://reviews.llvm.org/D144084
Allow controlling the CodeGenOpt::Level independent of the LTO
optimization level in LLD via new options for the COFF, ELF, MachO, and
wasm frontends to lld. Most are spelled as --lto-CGO[0-3], but COFF is
spelled as -opt:lldltocgo=[0-3].
See D57422 for discussion surrounding the issue of how to set the CG opt
level. The ultimate goal is to let each function control its CG opt
level, but until then the current default means it is impossible to
specify a CG opt level lower than 2 while using LTO. This option gives
the user a means to control it for as long as it is not handled on a
per-function basis.
Reviewed By: MaskRay, #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D141970
By using emplace_back, as well as converting some loops to for-each, we can do more efficient vectorization.
Make copy constructor for TemporaryFile noexcept.
Reviewed By: #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D139552
Similar to how `makeArrayRef` is deprecated in favor of deduction guides, do the
same for `makeMutableArrayRef`.
Once all of the places in-tree are using the deduction guides for
`MutableArrayRef`, we can mark `makeMutableArrayRef` as deprecated.
Differential Revision: https://reviews.llvm.org/D141814
For each symbol in a /delayloaded library, lld injects a small piece of
code to handle the symbol lazy loading. This code doesn't have unwind
information, which may be troublesome.
Provide these information for AMD64.
Thanks to Yannis Juglaret <yjuglaret@mozilla.com> for contributing the
unwinding info and for his support while crafting this patch.
Fix#59639
Differential Revision: https://reviews.llvm.org/D141691
