[AVR] Force relocations for non-encodable jumps (#121498)

This commit changes the branch emission logic so that instead of
throwing the "branch target out of range" error, we emit a relocation
ins

[AVR] Force relocations for non-encodable jumps (#121498)

This commit changes the branch emission logic so that instead of
throwing the "branch target out of range" error, we emit a relocation
instead.

show more ...

[ARM] Remove unused includes (NFC) (#116155)

Identified with misc-include-cleaner.

Reland "[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions. (PR #111970)" (#112877)

**Change relanded after feedback on failures and improvements to the
check of the addend. Original PR #

Reland "[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions. (PR #111970)" (#112877)

**Change relanded after feedback on failures and improvements to the
check of the addend. Original PR #111970**
Changes from original patch:
- The value that is being checked has changed, it is now correctly
checking any Addend for the instruction, rather than the Value. The
addend is kept within the Target data structure from my investigation.
- Removed changes to the following tests due to the original behaviour
being correct, and my original patch causing unexpected errors
- llvm/test/MC/ARM/Windows/mov32t-range.s
- llvm/test/MC/MachO/ARM/thumb2-movw-fixup.s

As per the ARM ABI, the MOVT and MOVW instructions should have addends
that fall within a 16bit signed range. LLVM does not check this so it is
possible to use addends that are beyond the accepted range. These
addends are silently truncated.

A new check is added to ensure the addend falls within the expected
range, rejecting an addend that falls outside with an error.

Information relating to the ABI requirements can be found here:
https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#addends-and-pc-bias-compensation

show more ...

Revert "[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions.… (#112184)

… (#111970)"

I was made aware of breakages in Windows/ARM, so reverting while I
investigate.

This reverts comm

Revert "[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions.… (#112184)

… (#111970)"

I was made aware of breakages in Windows/ARM, so reverting while I
investigate.

This reverts commit f3aebe623b49b7ae14d0f0996999114aac052e4b.

show more ...

[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions. (#111970)

Previously, any value could be used for the MOVT and MOVW instructions,
however the ARM ABI dictates that the addend should b

[llvm][ARM] Add Addend Checks for MOVT and MOVW instructions. (#111970)

Previously, any value could be used for the MOVT and MOVW instructions,
however the ARM ABI dictates that the addend should be a signed 16 bit
value. To ensure this is followed, the Assembler will now check that
when using these instructions, the addend is a 16bit signed value, and
throw an error if this is not the case.

Information relating to the ABI requirements can be found here:
https://github.com/ARM-software/abi-aa/blob/main/aaelf32/aaelf32.rst#addends-and-pc-bias-compensation

show more ...

[ARMAsmBackend] Add checks for relocation addends in assembler (#109969)

This PR adds checks that any addends attached to branch instructions are
valid, and can be properly encoded in the branch in

[ARMAsmBackend] Add checks for relocation addends in assembler (#109969)

This PR adds checks that any addends attached to branch instructions are
valid, and can be properly encoded in the branch instruction. Before
this fix, the assembler would silently truncate or round invalid addend
values, creating incorrect branch instructions.

show more ...

[ARM] Use MCRegister in more places. NFC

[ARM] Replace a hardcoded 14 used as an MCRegister index with ARM::LR.

LR is R14, but this data structure is indexed by MCRegister not
encoding. It's in a debug message so I guess no one ever notice

[ARM] Replace a hardcoded 14 used as an MCRegister index with ARM::LR.

LR is R14, but this data structure is indexed by MCRegister not
encoding. It's in a debug message so I guess no one ever noticed.

Found while auditing places that should use MCRegister.

show more ...

[MC] Make MCRegisterInfo::getLLVMRegNum return std::optional<MCRegister>. NFC (#107776)

[ARM] [Windows] Error out on branch relocations that require a symbol offset (#101906)

This adds the same kind of verification for ARM, as was added for
AArch64 in 1e7f592a890aad860605cf5220530b374

[ARM] [Windows] Error out on branch relocations that require a symbol offset (#101906)

This adds the same kind of verification for ARM, as was added for
AArch64 in 1e7f592a890aad860605cf5220530b3744e107ba. This allows
catching issues at assembly time, instead of having the linker
misinterpret the relocations (as the linker ignores the symbol offset).
This verifies that the issue fixed by
8dd065d5bc81b0c8ab57f365bb169a5d92928f25 really is fixed, and points out
explicitly if the same issue appears elsewhere.

Note that the parameter Value in the adjustFixupValue function is offset
by 4 from the value that is stored as immediate in the instructions, so
we compare with 4, when we want to make sure that the written immediate
will be zero.

show more ...

[LLVM] [MC] Update frame layout & CFI generation to handle frames larger than 2gb (#99263)

Rebase of #84114. I've only included the core changes to frame layout
calculation & CFI generation which s

[LLVM] [MC] Update frame layout & CFI generation to handle frames larger than 2gb (#99263)

Rebase of #84114. I've only included the core changes to frame layout
calculation & CFI generation which sidesteps the regressions found after
merging #84114. Since these changes are a necessary precursor to the
overall fix and are themselves slightly beneficial as CFI is now
generated correctly, I think it is reasonable to merge this first step.

---

For very large stack frames, the offset from the stack pointer to a
local can be more than 2^31 which overflows various `int` offsets in the
frame lowering code.

This patch updates the frame lowering code to calculate the offsets as
64-bit values and fixes CFI to use the corrected sizes.

After this patch, additional work is needed to fix offset truncations in
each target's codegen.

show more ...

[ARM] Work around Clang 9 after MCCFIInstruction::OpType uses uint8_t

ARMAsmBackend.cpp:1205:57: error: use of overloaded operator '<<' is ambiguous (with operand types 'llvm::raw_ostream' and
'llv

[ARM] Work around Clang 9 after MCCFIInstruction::OpType uses uint8_t

ARMAsmBackend.cpp:1205:57: error: use of overloaded operator '<<' is ambiguous (with operand types 'llvm::raw_ostream' and
'llvm::MCCFIInstruction::OpType')
"unwind encoding, opcode=" << Inst.getOperation()
~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~

show more ...

[MC] Remove unused MCAsmLayout declarations and includes

[MC] Remove two unused parameters from MCAsmBackend::fixupNeedsRelaxation

fixupNeedsRelaxation is a simple implementation for
fixupNeedsRelaxationAdvanced. Its users do not utilize MCAsmLayout or
MC

[MC] Remove two unused parameters from MCAsmBackend::fixupNeedsRelaxation

fixupNeedsRelaxation is a simple implementation for
fixupNeedsRelaxationAdvanced. Its users do not utilize MCAsmLayout or
MCRelaxableFragment.

Follow-up to 22c7317f1e954b34a46640db5d509bae1c633348
("[MC] Remove the MCAsmLayout parameter from relocation related functions").

show more ...

Revert rG58de1e2c5eee548a9b365e3b1554d87317072ad9 "Fix stack layout for frames larger than 2gb (#84114)"

This is failing on some EXPENSIVE_CHECKS buildbots

Fix stack layout for frames larger than 2gb (#84114)

For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the fram

Fix stack layout for frames larger than 2gb (#84114)

For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code.

This patch updates the frame lowering code to calculate the offsets as 64-bit values and resolves the overflows, resulting in the correct codegen for very large frames.

Fixes #48911

show more ...

[ARM,MC] Support FDPIC relocations

Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems.
GCC/binutils/qemu support FDPIC ABI for ARM
(https://github.com/mickael-guene/fdpic_doc).
_

[ARM,MC] Support FDPIC relocations

Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems.
GCC/binutils/qemu support FDPIC ABI for ARM
(https://github.com/mickael-guene/fdpic_doc).
_ARM FDPIC Toolchain and ABI_ provides a summary.

This patch implements FDPIC relocations to the integrated assembler.
There are 6 static relocations and 2 dynamic relocations, with
R_ARM_FUNCDESC as both static and dynamic.

gas requires `--fdpic` to assemble data relocations like `.word f(FUNCDESC)`.
This patch adds `MCTargetOptions::FDPIC` and reports an error if FDPIC
is not set.

Pull Request: https://github.com/llvm/llvm-project/pull/82187

show more ...

[llvm][MC][ARM] Don't autoresolve fixups (#76574)

Removes logic that caused some fixups to be marked as resolved in the
assembler without actually resolving them. Assembler must either resolve
the

[llvm][MC][ARM] Don't autoresolve fixups (#76574)

Removes logic that caused some fixups to be marked as resolved in the
assembler without actually resolving them. Assembler must either resolve
the fixup, reject the code (error out) or defer the resolution to the
linker. In general assembler can resolve offsets in pcrel instructions
if the symbol referred to is in the same section and it cannot make
assumptions about relative position of sections. For example, when LDRD
instruction in arm mode is encountered, fixup_arm_pcrel_10_unscaled is
raised. Prior to https://github.com/llvm/llvm-project/pull/72873/ the
assembler would always mark it as resolved without generating a
relocation. The resulting code would likely be incorrect whenever the
label referred to is in a different section.

This patch finishes the series to prevent incorrect code being generated
for pcrel instructions referring to labels in different sections. This
kind of assembly code is very rare and most likely a user error, so both
options (relocation or error) are acceptable. In previous patches this
was resolved by adding relocations. Here, for VLDR instructions an error
is generated as relocation does not exist for Thumb mode and we wanted
the tool's behaviour to be consistent across modes. In the LDRD case,
Thumb mode does not have a relocation and errors out, but LDRD in Arm
mode generates R_ARM_LDRS_PC_G0 relocation because its fixup kind is
shared with other instructions.

It also fixed the case when ADR is used in the big-endian mode, which is
not covered by the ADR patch.

Patch series:
https://github.com/llvm/llvm-project/pull/72873 - LDRx
https://github.com/llvm/llvm-project/pull/73834 - ADR
this PR - LDRD and VLDR

show more ...

[RISCV][MC] Pass MCSubtargetInfo down to shouldForceRelocation and evaluateTargetFixup. (#73721)

Instead of using the STI stored in RISCVAsmBackend, try to get it from
the MCFragment.

This addre

[RISCV][MC] Pass MCSubtargetInfo down to shouldForceRelocation and evaluateTargetFixup. (#73721)

Instead of using the STI stored in RISCVAsmBackend, try to get it from
the MCFragment.

This addresses the issue raised here
https://discourse.llvm.org/t/possible-problem-related-to-subtarget-usage/75283

show more ...

[llvm][MC][ARM][Assembly] Emit relocations for ADRs and big-endian targets (#73834)

Follow-up on https://github.com/llvm/llvm-project/pull/72873/

When ADR/LDR instructions reference a label i

[llvm][MC][ARM][Assembly] Emit relocations for ADRs and big-endian targets (#73834)

Follow-up on https://github.com/llvm/llvm-project/pull/72873/

When ADR/LDR instructions reference a label in a different section, the
offset is not known until link time, however, the assembler assumes it
can resolve them in some cases.

The previous patch addressed the issue for most LDR instructions,
focusing on little-endian targets.

This patch addresses the remaining work for ADRs and big-endian targets.

show more ...

[llvm][MC][ARM][Assembly] Emit relocations for LDRs (#72873)

It's possible (though inadvisable) to use LDR and refer to labels in
different
sections. In the Arm state, the assembler resolves the L

[llvm][MC][ARM][Assembly] Emit relocations for LDRs (#72873)

It's possible (though inadvisable) to use LDR and refer to labels in
different
sections. In the Arm state, the assembler resolves the LDR instruction
without
emitting a relocation. That's incorrect because the assembler cannot
make any
assumptions about the relative position of the sections and the compiler
output
is therefore wrong.

This patch ensures relocations are generated for all `LDR <Rt...>,
label`
instructions in the Arm state (little endian). This is not necessary
when the
label is in the same section but the relocation is now generated
regardless.
Instructions that now generate relocations have been removed from the
pcrel-global.s test.

Fortunately, LLD already implements the generated relocations and can
fix LDR
instructions when the symbol is in a different section, or report an
error if
the offset is too large for the immediate field in the particular LDR's
encoding.

The patch to address this problem for big endian targets will follow, as
well
as a fix for ADR that exhibits a similar behavior.

show more ...

Use llvm::endianness::{big,little,native} (NFC)

Note that llvm::support::endianness has been renamed to
llvm::endianness while becoming an enum class as opposed to an
enum. This patch replaces suppo

Use llvm::endianness::{big,little,native} (NFC)

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}.

show more ...

Use llvm::endianness (NFC)

Now that llvm::support::endianness has been renamed to
llvm::endianness, we can use the shorter form. This patch replaces
support::endianness with llvm::endianness.

[ARM] add Thumb-1 8-bit movs/adds relocations to LLVM

This patch adds the LLVM-side plumbing for the following relocations:
- R_ARM_THM_ALU_ABS_G0_NC
- R_ARM_THM_ALU_ABS_G1_NC
- R_ARM_THM_ALU_ABS_G2

[ARM] add Thumb-1 8-bit movs/adds relocations to LLVM

This patch adds the LLVM-side plumbing for the following relocations:
- R_ARM_THM_ALU_ABS_G0_NC
- R_ARM_THM_ALU_ABS_G1_NC
- R_ARM_THM_ALU_ABS_G2_NC
- R_ARM_THM_ALU_ABS_G3

(see section 5.6.1.5, Static Thumb16 relocations, of the AArch32 ELF Arm ABI:
https://github.com/ARM-software/abi-aa/blob/844a79fd4c77252a11342709e3b27b2c9f590cf1/aaelf32/aaelf32.rst#5615static-thumb16-relocations)

Which can respectivly be generated by prefixing assembly symbols with:
- :lower0_7:
- :lower8_15:
- :upper0_7:
- :upper8_15:

LLD support for these relocations will be added in a follow-up patch

Reviewed By: john.brawn, MaskRay

Differential Revision: https://reviews.llvm.org/D149443

show more ...

Reland "D144999 [MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

Reasons for rolling forward:
- the crash reported from Chromium was fi

Reland "D144999 [MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs."

Reasons for rolling forward:
- the crash reported from Chromium was fixed in D151824 (not related to this patch at all)
- since D152824 was committed, it should now be safe to roll this forward.

New change:
- add an additional _ in name check

This reverts commit 4980eead4d0b4666d53dad07afb091375b3a13a0.

show more ...