In https://reviews.llvm.org/D137982 we found that on Mach-O private
aliases could trigger an assert in lld when the aliasee was a
weak_def_can_be_hidden symbol.
This appears to be incorrect, and should be allowed in Mach-O.
Disallowing this behavior is also inconsistent with how ld64 handles
a private alias to weak_def_can_be_hidden symbols.
This patch removes the assert and tests that LLD handles such aliases
gracefully.
Reviewed By: #lld-macho, int3
Differential Revision: https://reviews.llvm.org/D141082
In ThumbThunk::isCompatibleWith, we check if we can use short thunks if we are
within branch range. However these short thumb thunks will generate b.w
instructions, and these are not available on pre branch range extension
architectures.
On these architectures (v4, v5, and most of v6), we could replace the b.w with a
Thumb b (2) instruction, but that would in an ideal situation only give us an
extra range of 2048 bytes on top of the 4MB range of a BL, if a thunk section
happens to be placed on the outer range of a BL and the stars are aligned. It
doesn't seem worth it.
What would be worth it is a state change to Arm and a subsequent branch to
either Arm or Thumb code. But that's the subject of another patch.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D140633
We can technically handle them, but since they shouldn't come up in any
real-world programs (since ld64 dedups strings unconditionally), there's
no reason to support them.
It's a thoroughly untested code path too -- as evidenced by the fact
that the only test this change breaks is one that verifies that we
reject relocations when dedup'ing. There is no test that covers the case
where we handle relocations in cstring sections when dedup is disabled.
Reviewed By: #lld-macho, oontvoo, keith, thakis
Differential Revision: https://reviews.llvm.org/D141025
I wasn't previously aware of the `llvm-otool -o` flag; that gives us
output that's a lot easier to parse.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D141024
This check was previous disabled because the test kept failing on ARM64. The output from reported failure message
gave the impression that the bundle was created as an x86-64 bundle but upon further inspection, I believe that's
a bug in llvm-otool where it prints both -h and -f for both input files on ARM64.
So the "fix" here is to rewrite the test to run the two otool commands separately but concatenate the
output into one file for checking.
Differential Revision: https://reviews.llvm.org/D140987
The relocation 'R_AVR_LDS_STS_16' is introduced for the compact
16-bit LDS/STS instructions on AVRTiny devices.
Reviewed By: MaskRay, aykevl
Differential Revision: https://reviews.llvm.org/D139807
For x86-32, {clang,gcc} -fno-plt uses `call *___tls_get_addr@GOT(%reg)` instead
of `call ___tls_get_addr@PLT`. GD to IE/LE relaxations need to shift the offset
by one while LD to LE relaxation needs to use a different code sequence.
While here, fix some comments.
Fix https://github.com/llvm/llvm-project/issues/59769
Differential Revision: https://reviews.llvm.org/D140813
Errors / warnings that originate from a particular file should be of the
form `$file: $message`.
Reviewed By: #lld-macho, keith
Differential Revision: https://reviews.llvm.org/D140634
This will enable us to re-land {D139069}.
The issue with the original diff was that we were folding all
private-label symbols. We were not merging the symbol flags during this
folding; instead we just made all references to the folded symbol point
to its aliasee. This caused some flags to be incorrectly discarded. This
surfaced as code that was incorrectly stripped due to LLD dropping the
`.no_dead_strip` flag.
This diff fixes things by only folding flag-less private-label aliases.
Most (maybe all) of the `ltmp<N>` symbols that are generated by the MC
aarch64 backend are flag-less, so this conservative folding behavior
does the job.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D140606
This is to work around a singularity container issue we ran into recently. The
container fails to honor the time zone setting (TZ=UTC) when executing the touch
command. Replacing UTC with GMT worked correctly in the container. This change
does not change (at least not intentionally) the function of the test in any way
since GMT and UTC should be equivalent AFAIK. Please refer to the discussions in
D139980 for more background information.
Reviewed By: int3, #lld-macho
Differential Revision: https://reviews.llvm.org/D140233
By default ld64 ignores invalid LC_LINKER_OPTIONS unless the link fails,
in which case it prints a warning. Originally lld chose to be strict
about these, but it has uncovered that many of these exist in open
source projects today, since before developers never would have noticed
this issue. In order to make adoption of lld easier, this mirrors ld64's
behavior, while also adding a `--strict-auto-link-options` flag if
projects want to audit their libraries for these invalid options.
More discussion on https://reviews.llvm.org/D140225
Fixes https://github.com/llvm/llvm-project/issues/59627
Differential Revision: https://reviews.llvm.org/D140491
Previously by default, when not using `--ifc=`, lld would not
deduplicate string literals. This reveals reliance on undefined behavior
where string literal addresses are compared instead of using string
equality checks. While ideally you would be able to easily identify and
eliminate the reliance on this UB, this can be difficult, especially for
third party code, and increases the friction and risk of users migrating
to lld. This flips the default to deduplicate strings unless
`--no-deduplicate-strings` is passed, matching ld64's behavior.
Differential Revision: https://reviews.llvm.org/D140517
We now handle the GOT, TLV, and stubs/lazy pointer sections.
Reviewed By: #lld-macho, thevinster, thakis
Differential Revision: https://reviews.llvm.org/D139762
This patch relaxes the constraints on the error message saved in PDBInputFile when failing to load a pdb file.
Storing an `Error` member infers that it must be accessed exactly once, which doesn't fit in several scenarios:
- If an invalid PDB file is provided as input file but never used, a loading error is created but never handled, causing an assert at shutdown.
- PDB file created using MSVC's `/Zi` option : The loading error message must be displayed once per obj file.
Also, the state of `PDBInputFile` was altered when reading (taking) the `Error` member, causing issues:
- accessing it (taking the `Error`) makes the object look valid whereas it's not properly initialized
- read vs write concurrency on a same `PDBInputFile` in the ghash parallel algorithm
The solution adopted here was to instead store an optional error string, and generate Error objects from it on demand.
Differential Revision: https://reviews.llvm.org/D140333
changes:
- BLX: The Arm architecture versions that support the branch and link
instruction (BLX), can rewrite BLs in place when a state change from Arm<->Thumb
is required. Armv4T does not have BLX and so needs thunks for state changes.
- v4T Thumb long branches needed their own thunk. We could have used the v6M
implementation, but v6M doesn't have Arm state and must resolve to rather
inefficient stack reshuffling. We also can't reuse v7 thumb thunks as they use
MOVV/MOVT, which wasn't available yet for v4T.
- Remove the `lack of BLX' warning. LLVM only supports Arm Architecture versions
upwards of v4, which we now all support in LLD.
- renamed existing thunks to better reflect their use:
ARMV5ABSLongThunk -> ARMV5LongLdrPcThunk,
ARMV5PILongThunk -> ARMV4PILongThunk
- removed isCompatibleWith method from ARMV5ABSLongThunk and ARMV5PILongThunk,
as they were identical to the ARMThunk parent class implementation.
Support for (efficient) position independent thunks for v4T will be added in a
follow-up patch, including possible related thunk renaming and code comment
cleanup.
Reviewed By: MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D139888
This reverts commit 09c5aab7f8.
New changes:
Temporarily skip checking the output bundle's cpu/cpu-subtype
Suspected there's a bug in selecting targets which caused the produced bundle
to be arm64 bundle (even though it was specifically linked with -arch x86_64).
The current test that link succeeded should be sufficient, because
it would have failed with "unable to find matching tagets" prior to this patch.
Differential Revision: https://reviews.llvm.org/D139572
This reverts commit 52a118d08f.
New changes:
Fix tests to dump both slices in the fat-archive because otool
isn't deterministic about which slice it prints across different archs.
(It printed x86 on x86 machines but arm64 on arm64, this was why
the test failed on arm64)
Differential Revision: https://reviews.llvm.org/D139572
We only want to rewrite paths to files that the linker looks up. Files
under RPATH are looked up at runtime by dyld.
Reviewed By: #lld-macho, keith
Differential Revision: https://reviews.llvm.org/D140167
The test currently uses `touch -t` (e.g., `env TZ=UTC touch -t
"197001010000.16"`) to set file timestamps. However, this does not seem to set
the time zone correctly in a singularity container. While this is probably a
bug/limitation of the singularity container, but we can instead use `touch
-d` (e.g., `touch -d "1970-01-01 00:00:16 UTC"`) to achieve the same result
without relying on a fix from singularity. Thoughts?
Reviewed By: int3, #lld-macho
Differential Revision: https://reviews.llvm.org/D139980
This covers the special section ordering handling. This chooses to fake the sections vs creating them organically which is probably a bit easier to maintain.
Differential Revision: https://reviews.llvm.org/D139959
We were previously ignoring weak externals during these searches (which
are used for the entry point, exports, and subsystem inference), which
differed from link.exe behavior. It also meant that we could get
different behavior when linking an object file directly vs. packaging it
into a static library, because static library symbol name directories
include weak externals.
Reviewed By: mstorsjo, yozhu
Differential Revision: https://reviews.llvm.org/D139764
This reverts commit 66692c822a.
New changes:
- update test to require aarch64
- update test to not hard-code cpu[sub] type values (since they could change)
- update test to temporarily skip windows (because llvm-mc on windows doesn't seem to work with triple arm64-apple-macos)
Differential Revision: https://reviews.llvm.org/D139572
With newer versions of ld64 it generates an adhoc signature by default
for all arm64 simulator targets. This default is especially important
for unit test targets that rarely have custom codesigning requirements
but otherwise won't run on arm64 macs.
Differential Revision: https://reviews.llvm.org/D139672
I tried `-undefined suppress` without `-flat_namespace`.
lld printed `'-undefined suppress' only valid with '-flat_namespace'`
followed by many many screenfuls of error messages about undefined
symbols, making the original diag hard to see.
This is probably the common case when using `-undefined`, so let's
just abort the link immediately when there's an invalid `-undefined`
arg.
Differential Revision: https://reviews.llvm.org/D139559
Currently we take the first SHT_RISCV_ATTRIBUTES (.riscv.attributes) as the
output. If we link an object without an extension with an object with the
extension, the output Tag_RISCV_arch may not contain the extension and some
tools like objdump -d will not decode the related instructions.
This patch implements
Tag_RISCV_stack_align/Tag_RISCV_arch/Tag_RISCV_unaligned_access merge as
specified by
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#attributes
For the deprecated Tag_RISCV_priv_spec{,_minor,_revision}, dump the attribute to
the output iff all input agree on the value. This is different from GNU ld but
our simple approach should be ok for deprecated tags.
`RISCVAttributeParser::handler` currently warns about unknown tags. This
behavior is retained. In GNU ld arm, tags >= 64 (mod 128) are ignored with a
warning. If RISC-V ever wants to do something similar
(https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/352), consider
documenting it in the psABI and changing RISCVAttributeParser.
Like GNU ld, zero value integer attributes and empty string attributes are not
dumped to the output.
Reviewed By: asb, kito-cheng
Differential Revision: https://reviews.llvm.org/D138550
Allowing incorrect version scripts is not a helpful default. Flip that
to help users find their bugs at build time rather than at run time.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135402
I'll be making changes to the ObjC implementation (bug fix) in a later
change, and I noticed that this test isn't being tested at all. Fix that up
here separately so further changes are easier to differentiate.
Reviewed By: #lld-macho, thakis, int3
Differential Revision: https://reviews.llvm.org/D139396
The main motivation for this change is to avoid ambiguity because
mapping symbol names may not be unique across a binary and do not allow uniquely
identifying target address. So that mapping symbols used as branch target
labels make llvm-objdump output less readable.
Another point is that mapping symbols sometimes appear in
non-allocatable sections, like debug info sections which make objdump
output even more confusing.
For example, a small AArch64 executable may contain plenty of `$d[.*]`
symbols and none of them would be useful as a label for resolving
a branch or a memory operand target address:
```
0000000000000254 l .note.ABI-tag 0000000000000000 $d
00000000000008d4 l .eh_frame 0000000000000000 $d
0000000000000868 l .rodata 0000000000000000 $d
0000000000011028 l .data 0000000000000000 $d
0000000000010db8 l .fini_array 0000000000000000 $d
0000000000010db0 l .init_array 0000000000000000 $d
00000000000008e8 l .eh_frame 0000000000000000 $d
0000000000011034 l .bss 0000000000000000 $d
```
Note that GNU objdump doesn't use mapping symbols as branch target
labels for all targets that support such symbols (ARM, AArch64, CSKY).
Differential Revision: https://reviews.llvm.org/D139131
CodeView doesn't have the ability to represent variables
in other ways than as in registers or memory values, but
LLVM very often transforms simple values into constants,
consider this program:
int f () { int i = 123; return i; }
LLVM will transform `i` into a constant value and just
leave behind a llvm.dbg.value, this can't be represented
as a S_LOCAL record in CodeView. But we can represent it
as a S_CONSTANT record.
This patch checks if the location of a debug value is null,
then we will insert a S_CONSTANT record instead of a S_LOCAL
value with the flag "OptimizedAway".
In lld we then output the S_CONSTANT in the right scope, before
they where always inserted in the global stream, now we check
the scope before inserting it.
This has shown to improve debugging for our developers
internally.
Fixes to llvm/llvm-project#55958
Reviewed By: aganea
Differential Revision: https://reviews.llvm.org/D138995
