Per the psABI, the arch string should be normalised to (amongest other
things) always include the full version of each extension in form
zfoo1p0. riscv-attributes-place.s didn't conform to this, which is not a
problem for the current parsing logic, but this behaviour would change
with a patch I'm about to propose.
This makes riscv-sttributes-place.s feature a valid arch string, and
maintains test coverage for this particular form of invalid arch string
by adding it to riscv-attributes.s.
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
[TextAPI] Implement TBDv5 Reader
Introduce initial reader for TBDv5 which is in JSON. This captures all
the currently understood fields within the internal structure
`InterfaceFile`.
New fields & follow up tests will be followed up in future PRs.
Reviewed By: pete
Differential Revision: https://reviews.llvm.org/D144156
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
Our bot has been failing https://lab.llvm.org/buildbot/#/builders/178/builds/3967:
Assertion `isecEnd - isecVA <= forwardBranchRange && "should only finalize sections in jump range"' failed.
I think this is due to the use of size_t, which is 32 bit on 32 bit,
for a value used in some 64 bit address calculations. Which was added in
https://reviews.llvm.org/D144029.
Switching to uint64_t fixes the issues.
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
This patch is related to the discussion in
<https://discourse.llvm.org/t/rfc-resolving-issues-related-to-extension-versioning-in-risc-v/68472/1>.
It slightly expands the coverage of behaviour for unrecognized
extensions (there are slightly different forms of error for zfoo vs e.g.
'y'), and adds coverage for an extension with an
unrecognized/unsupported version number.
Use "unrecognized" terminology because the expectation is the error
checking will be reduced in a follow-up patch posted for review.
Change:
- Replacing the memcpy that assume little endian with the endian-aware write.
Shouldn't affect the output for now, just a prerequisite for the next patches.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D140201
We previously neglected this, leading us to underestimate the maximum
possible branch address offset.
Fixing this should allow us to reduce `slop` to more reasonable
levels. I've lowered it to 256 for now, though I suspect we could go
lower.
Fixes https://github.com/llvm/llvm-project/issues/59259.
Reviewed By: serge-sans-paille
Differential Revision: https://reviews.llvm.org/D144029
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.
Having symVector makes iteration efficient and is actually more
efficient than using llvm::DenseMap<llvm::CachedHashStringRef, Symbol
*>, so the FIXME comment can be removed. Using an alternative
implementation ankerl/unordered_dense.h decreases link time for chromium
by 0.x% but I am unsure it justifies the extra header file.
Fix https://github.com/llvm/llvm-project/issues/60392
```
// a.cc
void raise() { throw 42; }
bool foo() {
try { raise(); } catch (int) { return true; }
return false;
}
int main() { foo(); }
```
```
clang++ --target=x86_64-linux-gnu -fno-pic -mcmodel=large -no-pie -fuse-ld=lld -z notext a.cc -o a && ./a
clang++ --target=aarch64-linux-gnu -fno-pic -no-pie -fuse-ld=lld -Wl,--dynamic-linker=/usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 -Wl,-rpath=/usr/aarch64-linux-gnu/lib -z notext a.cc -o a && ./a
```
Both commands fail because we produce a dynamic relocation for
R_X86_64_64/R_AARCH64_ABS64 in .eh_frame which will be adjusted to a wrong
offset by `SectionBase::getOffset` after D122459.
Since GNU ld uses a canonical PLT entry instead of a dynamic relocation for
.eh_frame, we follow suit as well to avoid the issue.
Mips has an ABI issue (https://github.com/llvm/llvm-project/issues/5837) and we
don't implement GNU ld's DW_EH_PE_absptr conversion. mips64-eh-abs-reloc.s wants
a dynamic relocation, so keep the original behavior for EM_MIPS.
Differential Revision: https://reviews.llvm.org/D143136
gcc warned like
../../lld/ELF/InputSection.cpp:75:37: warning: ISO C++11 requires at least one argument for the "..." in a variadic macro
75 | invokeELFT(parseCompressedHeader);
| ^
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
This is what ld64 does, and also what we already do for most of the
other load commands. I'm not aware of a good way to test this, but I
don't think it really matters.
Differential Revision: https://reviews.llvm.org/D141462
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
string_view has a slightly weaker contract, which only specifies whether
the value is bigger or smaller than 0. Adapt users accordingly and just
forward to the standard function (that also compiles down to memcmp)
This nearly mirrors ld64's error for this case:
ld: warning: ignoring file path/to/file, file is universal (armv7,arm64) but does not contain the x86_64 architecture: path/to/file
Differential Revision: https://reviews.llvm.org/D141729
D139623 replaces CMAKE_CFG_INTDIR
with '.' for multi-config builds. However, this change has
not been reflected in mlir, flang, polly, lld, and clang.
The patch updates the path to LLVMConfig.cmake for those
projects.
Reviewed By: sebastian-ne
Differential Revision: https://reviews.llvm.org/D141538
- Position independent thunks now work for both Armv4 and Armv4T
- Armv4 arm->arm thunks don't emit a BX anymore, which doesn't exist for the
arch. This fixes https://github.com/llvm/llvm-project/issues/50764.
- Armv4 and Armv4T both have the same arm->arm behaviour. Which also is
desirable for the above ticket.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D141272
Adds support for the following flags:
* --thinlto-index-only, --thinlto-index-only=
* --thinlto-emit-imports-files
* --thinlto-emit-index-files
* --thinlto-object-suffix-replace=
* --thinlto-prefix-replace=
See https://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html
for some words on --thinlto-index-only.
I don't really need the other flags, but they were in the vicinity
and _someone_ might need them, so I figured I'd add them too.
`-object_path_lto` now sets `c.AlwaysEmitRegularLTOObj` as in the other ports,
which means it can now only point to a filename for non-thin LTO.
I think that was the intent of D129705 anyways, so update
test/MachO/lto-object-path.ll to use a non-thin bitcode file for that test.
Differential Revision: https://reviews.llvm.org/D138451
This mirrors ld64's behavior. In many cases this likely still leads to a
link failure but if you didn't actually use anything from the library
it can be ignored. If you care about these invalid cases -fatal_warnings
still upgrades it back to an error.
Example: https://github.com/keith/ld64.lld/issues/3
Differential Revision: https://reviews.llvm.org/D141638
