| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
GNU ld silently accepts the -rpath option for Windows targets, as a
no-op.
This has lead to some build systems (and users) passing this option
while building for Windows/MinGW, even if Windows doesn't have any
concept like rpath.
Older versions of Conan did include -rpath in the pkg-config files it
generated, see e.g.
https://github.com/conan-io/conan/blob/17c58f0c61931f9de218ac571cd97a8e0befa68e/conans/client/generators/pkg_config.py#L104-L114
and
https://github.com/conan-io/conan/blob/17c58f0c61931f9de218ac571cd97a8e0befa68e/conans/client/build/compiler_flags.py#L26-L34
- and see https://github.com/mstorsjo/llvm-mingw/issues/300 for user
reports about this issue.
Recognize the option in LLD for MinGW targets, to improve drop-in
compatibility compared to GNU ld, but produce a warning to alert users
that the option really has no effect for these targets.
|
|
0f9fbbb63cfcd2069441aa2ebef622c9716f8dbb changed the version printouts.
This broke linker detection in Meson, when disambiguating between the
ld.lld and lld-link interfaces, in
https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67,
which checks for the string "(compatible with GNU linkers)" including
the parentheses.
Reinstate the parentheses in the printout here, for compatibility with
Meson. The printout looks a little odd in this form, "LLD 19.0.0
(https://github.com/llvm/llvm-project
173514d58ec4e6166670f1e37a038df3865c8b96) (compatible with GNU
linkers)", but works with Meson.
The Meson check is loosened in https://github.com/mesonbuild/meson/pull/13383,
but existing versions of Meson with the too strict check will be around
for quite some time, so we should only change LLD to the new form once
older versions of Meson aren't used for these targets any longer, i.e.
earliest within a few years.
|
|
Added LLVM repository and LLVM revision information for
`lld::getLLDVersion()`
Before this change:
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0 (compatible with GNU linkers)
```
After this change with LLVM_APPEND_VC_REV=on
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0 (https://github.com/yugier/llvm-project.git 4134b33c6a362cb462b335177d6d9e8235f04309), compatible with GNU linkers
```
with LLVM_APPEND_VC_REV=off
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0, compatible with GNU linkers
```
|
|
This fixes https://github.com/llvm/llvm-project/issues/93309, and seems
to match how GNU ld handles this case.
|
|
This reverts commit 67d20412b448533c77f54ac7a1e5d0775d273729.
This includes fixes for clanginstallapi.
|
|
This reverts commit 7e958f64efea6cb824e96ace51e021afbc150922.
Failing on multiple bots.
|
|
And use it to print the correct default OpenMP version for flang and
flang -fc1.
This change adds an optional `HelpTextsForVariants` to options. This
allows you to change the help text that gets shown in documentation and
`--help` based on the program its being generated for.
As `OptTable` needs to be constexpr compatible, I have used a std::array
of help text variants. Each entry is:
(list of visibilities) - > help text string
So for the OpenMP version we have (flang, fc1) -> "OpenMP version for
flang is...".
So you can have multiple visibilities use the same string. The number of
entries is currently set to 1, and the number of visibilities per entry
is 2, because that's the maximum we need for now. The code is written so
we can increase these numbers later, and the unused elements will be initialised.
I have not applied this to group descriptions just because I don't know
of one that needs changing. It could easily be enabled for those too if
needed. There are minor changes to them just to get it all to compile.
This approach of storing many help strings per option in the 1 driver
library seemed preferable to making a whole new library for Flang (even
if that would mostly be including stuff from Clang).
|
|
This has been a supported option for ELF and is added to the COFF Linker
in #85701
|
|
(#81475)
These were implemented in the COFF linker in
3923e61b96cf90123762f0e0381504efaba2d77a and
d12b99a4313816cf99e97cb5f579e2d51ba72b0b.
This matches the corresponding options in the ELF linker.
|
|
'arm64ecpe' was chosen arbitrarily as gcc MinGW doesn't provide EC
support.
|
|
This was missed when mass-adding support for other LTO options in
0b51e648307cf6c21c463d3e73e51c03aaa8c9e2.
Group the existing thinlto_cache_dir with these other options in a new
group, next to the other LTO options.
This skips adding the options --thinlto-emit-index-files and
--thinlto-single-module=, which don't seem to have corresponding options
on the lld-link level currently.
This should fix https://github.com/mstorsjo/llvm-mingw/issues/386.
|
|
This was present since when the MinGW LLD frontend first was merged in
894dbbe8eb0e3d8fc7d8746a76d2380f0c2b6c0f, where it most probably was a
leftover from earlier evolution of the patch.
|
|
This allows avoiding including some stray DWARF sections (e.g. from
toolchain provided files), when writing a PDB file.
While that probably could be considered reasonable default behaviour,
PDB writing and including DWARF sections are two entirely orthogonal
concepts, and GNU ld (which can generate PDB files these days) does
include DWARF unless -S/-s is passed, when creating a PDB.
|
|
[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.
|
|
Back when the --icf= option was hooked up in the MinGW frontend in LLD,
in 2017, lld-link didn't support safe ICF, and mapping it to noicf was
suggested in review: https://reviews.llvm.org/D40019
In 2018, in ab038025a50c79a89edb5832b163e8c729ceb703,
lld-link did get support for handling address significance tables,
allowing the ICF to operate safely on more sections.
Later in 2021, lld-link did get support for a separate safe ICF mode in
5bdc5e7efda4100c4d11085c2da8f1fb932ccce4 /
https://reviews.llvm.org/D97436.
Hook this up for the MinGW frontend as well.
|
|
Many of these options can be passed to the linker by the Clang
driver based on other options passed to Clang, after
a23bf1786be7c0738a4cf999c2957155bb32d5af. Before commit
5c92c9f34a7dba804479acef62c576d1a170ef1f, these were ignored by
lld, but now we're erroring out on the unrecognized options.
The ELF linker has even more LTO options available, but not
all of these are currently settable via the lld-link option
interface, and some aren't set automatically by Clang but only
if the user manually passes them - and thus probably aren't in
wide use so far. (Previously LLD/MinGW would have accepted them
silently but ignored them though.)
Differential Revision: https://reviews.llvm.org/D158887
|
|
This is modelled after how the ELF driver does it (see e.g.
https://reviews.llvm.org/D78158 for the source of the ELF
implementation); we need to intercept some options, but ignore GCC
specific ones that GCC passes regardless of whether GCC is using
LTO or not.
This is the second part of the fix for
https://github.com/mstorsjo/llvm-mingw/issues/349.
Differential Revision: https://reviews.llvm.org/D158412
|
|
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, 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
|
|
this is failing on bots, reverting to investigate.
This reverts commit a16104e6da6f36f3d72dbf53d10ba56495a0d65a.
|
|
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
|
|
This reverts commit aa495214b39d475bab24b468de7a7c676ce9e366.
As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch
allows for using LLD-as-a-lib. It also lets clients link only the drivers that
they want (see unit tests).
This also adds the unit test infra as in the other LLVM projects. Among the
test coverage, I've added the original issue from @krzysz00, see:
https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction
Important note: this doesn't allow (yet) linking in parallel. This will come a
bit later hopefully, in subsequent patches, for COFF at least.
Differential revision: https://reviews.llvm.org/D119049
|
|
This reverts commit 2700da5fe28d8b17c66e5c960d2188276a6ced39.
Reverting since this causes some test failures on our builders: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8778372807208184913/overview
|
|
As discussed in https://github.com/llvm/llvm-project/issues/53475 this patch allows using LLD-as-a-lib. It also lets clients link only the drivers that they want (see unit tests).
This also adds the unit test infra as in the other LLVM projects. Among the test coverage, I've added the original issue from @krzysz00, see: https://github.com/ROCmSoftwarePlatform/D108850-lld-bug-reproduction
Important note: this doesn't allow (yet) linking in parallel. This will come a bit later, in subsequent patches, for COFF at last.
Differential revision: https://reviews.llvm.org/D119049
|
|
The latter form is now preferred to be similar to C++20 starts_with.
This replacement also removes one function call when startswith is not inlined.
|
|
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
6c3ea866e93003e16fc55d3b5cedd3bc371d1fde.
I'll post a separate patch to deprecate
StringRef::{starts,ends}with_insensitive.
Differential Revision: https://reviews.llvm.org/D150506
|
|
The forwarding header is left in place because of its use in
`polly/lib/External/isl/interface/extract_interface.cc`, but I have
added a GCC warning about the fact it is deprecated, because it is used
in `isl` from where it is included by Polly.
|
|
I also ran `git clang-format` to get the headers in the right order for
the new location, which has changed the order of other headers in two
files.
|
|
This avoid rediscovering this table when reading each options, providing
a sensible 2% speedup when processing and empty file, and a measurable
speedup on typical workloads, see:
This is optional, the legacy, on-the-fly, approach can still be used
through the GenericOptTable class, while the new one is used through
PrecomputedOptTable.
https://llvm-compile-time-tracker.com/compare.php?from=4da6cb3202817ee2897d6b690e4af950459caea4&to=19a492b704e8f5c1dea120b9c0d3859bd78796be&stat=instructions:u
Differential Revision: https://reviews.llvm.org/D140800
|
|
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
The commit transitively includes lld/include/lld/Common/ErrorHandler.h into
lld/include/lld/Common/Driver.h, which is not intended.
|
|
call information
This avoids recomputing string length that is already known at compile time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This a recommit of e953ae5bbc313fd0cc980ce021d487e5b5199ea4 and the subsequent fixes caa713559bd38f337d7d35de35686775e8fb5175 and 06b90e2e9c991e211fecc97948e533320a825470.
The above patchset caused some version of GCC to take eons to compile clang/lib/Basic/Targets/AArch64.cpp, as spotted in aa171833ab0017d9732e82b8682c9848ab25ff9e.
The fix is to make BuiltinInfo tables a compilation unit static variable, instead of a private static variable.
Differential Revision: https://reviews.llvm.org/D139881
|
|
builtin and call information"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4 (part 2)"
Revert "Fix lldb option handling since e953ae5bbc313fd0cc980ce021d487e5b5199ea4"
GCC build hangs on this bot https://lab.llvm.org/buildbot/#/builders/37/builds/19104
compiling CMakeFiles/obj.clangBasic.dir/Targets/AArch64.cpp.d
The bot uses GNU 11.3.0, but I can reproduce locally with gcc (Debian 12.2.0-3) 12.2.0.
This reverts commit caa713559bd38f337d7d35de35686775e8fb5175.
This reverts commit 06b90e2e9c991e211fecc97948e533320a825470.
This reverts commit e953ae5bbc313fd0cc980ce021d487e5b5199ea4.
|
|
call information
This avoids recomputing string length that is already known at compile
time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 that into
account a GGC issue (probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181) when dealing with
intiailizer_list and constant expressions.
Workaround this by avoiding initializer list, at the expense of a
temporary plain old array.
Differential Revision: https://reviews.llvm.org/D139881
|
|
builtin and call information"
There are still remaining issues with GCC 12, see for instance
https://lab.llvm.org/buildbot/#/builders/93/builds/12669
This reverts commit 5ce4e92264102de21760c94db9166afe8f71fcf6.
|
|
call information
This avoids recomputing string length that is already known at compile
time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
This is a recommit of 719d98dfa841c522d8d452f0685e503538415a53 with a
change to llvm/utils/TableGen/OptParserEmitter.cpp to cope with GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
Differential Revision: https://reviews.llvm.org/D139881
|
|
builtin and call information"
Failing builds: https://lab.llvm.org/buildbot#builders/9/builds/19030
This is GCC specific and has been reported upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158
This reverts commit 719d98dfa841c522d8d452f0685e503538415a53.
|
|
call information
This avoids recomputing string length that is already known at compile
time.
It has a slight impact on preprocessing / compile time, see
https://llvm-compile-time-tracker.com/compare.php?from=3f36d2d579d8b0e8824d9dd99bfa79f456858f88&to=e49640c507ddc6615b5e503144301c8e41f8f434&stat=instructions:u
Differential Revision: https://reviews.llvm.org/D139881
|
|
This is a recommit of 8ae18303f97d5dcfaecc90b4d87effb2011ed82e,
with a few cleanups.
This avoids implicit conversion to StringRef at several points, which in
turns avoid redundant calls to strlen.
As a side effect, this greatly simplifies the implementation of
StrCmpOptionNameIgnoreCase.
It also eventually gives a consistent, humble speedup in compilation
time (timing updated since original commit).
https://llvm-compile-time-tracker.com/compare.php?from=de4b6a1bc64db33643f001ad45fae7b92b4a4688&to=c23a93d1292052b4be2fbe8c586fa31143d0c7ed&stat=instructions:u
Differential Revision: https://reviews.llvm.org/D139274
|
|
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
|
|
This maps to -errorlimit:<N> in the COFF linker and is functionally
identical to the same option in the ELF and MachO linker.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D137489
|
|
This matches how ld.bfd works in practice; this fixes
https://github.com/mstorsjo/llvm-mingw/issues/305.
Adding a test for the new lib name combination that this allows, but
also adding a few negative tests for combinations that aren't
matched when -static is specified (because this change in itself
didn't break any of the existing tests either).
The logic in how ld.bfd looks for various libraries based on
an -l<libname> argument is rather complex; the
ldemul_open_dynamic_archive function looks for various combinations:
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/emultempl/pep.em;h=e68d1e69f17ad73af065b6bed19ae89ded913172;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l2066
This function is only called if looking for dynamic libraries
(i.e. if -static wasn't specified):
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldfile.c;h=731ae5f7aedcf921bd36a1b32a3e0f5bfa189071;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l365
However even this function is skipped, it still looks for libraries
in the form of "lib<libname>.a" (this is what lld did before):
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldfile.c;h=731ae5f7aedcf921bd36a1b32a3e0f5bfa189071;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l440
But it also calls a format specific function called
ldemul_find_potential_libraries, which for PE targets looks for
files named "<libname>.lib":
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/emultempl/pep.em;h=e68d1e69f17ad73af065b6bed19ae89ded913172;hb=b51c2fec1da205ea3e7354cbb3e253018d64873c#l2175
Differential Revision: https://reviews.llvm.org/D135651
|
|
These will be LLD-specific options to support Control Flow Guard for the
MinGW target. They are disabled by default, but enabling `--guard-cf`
will also enable `--guard-longjmp` unless `--no-guard-longjmp` is also
specified. These options maps to `-guard:cf,[no]longjmp`.
Note that these features require the `_load_config_used` symbol to
contain the load config directory and be filled with the required
symbols. While current versions of mingw-w64 do not supply this symbol,
the user can provide their own version of it.
Reviewed By: MaskRay, rnk
Differential Revision: https://reviews.llvm.org/D132808
|
|
This adds support for the existing GNU ld command line option, which
allows excluding individual symbols from autoexport (when linking a
DLL and no symbols are marked explicitly as dllexported).
Differential Revision: https://reviews.llvm.org/D130118
|
|
Since binutils 2.36, GNU ld defaults to emitting base relocations,
and that version added the new option --disable-reloc-section to
disable it.
Differential Revision: https://reviews.llvm.org/D127478
|
|
Noticed in https://github.com/msys2/MINGW-packages/pull/10567.
Differential Revision: https://reviews.llvm.org/D118405
|
|
Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.
See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html
The previous land f860fe362282ed69b9d4503a20e5d20b9a041189 caused issues in https://lab.llvm.org/buildbot/#/builders/123/builds/8383, fixed by 22ee510dac9440a74b2e5b3fe3ff13ccdbf55af3.
Differential Revision: https://reviews.llvm.org/D108850
|
|
It seems to be causing issues on https://lab.llvm.org/buildbot/#/builders/123/builds/8383
|
|
Move all variables at file-scope or function-static-scope into a hosting structure (lld::CommonLinkerContext) that lives at lldMain()-scope. Drivers will inherit from this structure and add their own global state, in the same way as for the existing COFFLinkerContext.
See discussion in https://lists.llvm.org/pipermail/llvm-dev/2021-June/151184.html
Differential Revision: https://reviews.llvm.org/D108850
|
