link_elf: Make phdrs first page check actually fatal
Otherwise we'll print an error but carry on regardless, presumably
destined to walk off the end of the mapping.
Reported by: thebugfixers at pm.me
MFC after: 1 week
(cherry picked from commit 1e39a314d870e312f623199e146eda6bdbc293a3)
Merge commit 6b0a46958c56 from llvm-project (by Piotr Kubaj):
[libunwind][PPC64] Fix unw_getcontext corrupting callee-saved VSX registers on LE (#198371)
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
[13 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[9 lines not shown]
Merge commit cbf48349e3e1 from llvm-project (by Jessica Clarke):
[NFC][ELF][PPC64] Pass address not offset to writePPC64LoadAndBranch (#212275)
Every caller currently subtracts the TOC base in its argument, so move
that into common code inside writePPC64LoadAndBranch. This will also
allow a different computation to be used in some cases in a future
commit.
Note that offset is now unsigned not signed; even previously, all
arguments were uint64_t, and all uses are unsigned, so making it signed
doesn't make much sense.
MFC after: 1 week
(cherry picked from commit bcbcd7303009344dc1051e4601284620bca29be8)
libllvmminimal: Fix building with LLVM < 21 on riscv64
On most architectures we end up not needing ABIBreak.cpp as, although
some of the sources here do reference EnableABIBreakingChecks (or, if
assertions are disabled, DisableABIBreakingChecks) at a source level, we
compile with -ffunction-sections and -fdata-sections, and link with
--gc-sections, and it happens to be the case that all references can be
GC'ed. However, prior to LLVM 21, the RISC-V backend did not apply
-fdata-sections to .sdata, where references to these symbols end up, and
for some files we're building with such references we end up not being
able to GC .sdata due to the other unrelated data in it, meaning that we
do in fact need to build ABIBreak.cpp.
Whilst we could make this conditional on the architecture, it's a tiny
file, and it's a bit fragile to rely on GC behaviour, so just include it
unconditionally.
Reviewed by: dim, emaste
Fixes: 770cf0a5f02d ("Fixups after llvm-project main llvmorg-21-init-19288-gface93e724f4 merge")
[4 lines not shown]
link_elf: Make phdrs first page check actually fatal
Otherwise we'll print an error but carry on regardless, presumably
destined to walk off the end of the mapping.
Reported by: thebugfixers at pm.me
MFC after: 1 week
(cherry picked from commit 1e39a314d870e312f623199e146eda6bdbc293a3)
Merge commit 6b0a46958c56 from llvm-project (by Piotr Kubaj):
[libunwind][PPC64] Fix unw_getcontext corrupting callee-saved VSX registers on LE (#198371)
This is the first of two independent fixes for libunwind on ppc64le
(ELFv2 ABI, little-endian), where two separate bugs together cause
SIGSEGV during backtracing. This commit addresses the VSX register
corruption; the TOC-restore fault is handled in a follow-up. Both
were discovered while debugging lang/rust build failures with
RUST_BACKTRACE=1 on FreeBSD/powerpc64le (IBM POWER9).
On ppc64le, `unw_getcontext` saves each VS register with an in-place
`xxswapd n, n` followed by `stxvd2x`. The swap is needed because
`stxvd2x` stores doublewords in the wrong order on LE. However, the
macro never applies a second `xxswapd` to restore the register after
the store, so all 64 VS registers are permanently corrupted on return
from `unw_getcontext`.
This affects every callee-saved VSX register: f14-f31 (VSR14-VSR31)
[13 lines not shown]
Merge commit 26bf39cdba0b from llvm-project (by Jessica Clarke):
[ELF][PowerPC] Don't assume TOC pointer is valid in IPLT entries (#207555)
Unlike normal PLT entries, IPLT entries can be called indirectly even
when in PIEs/DSOs, and so there's no guarantee on what's in the TOC
pointer register at that time. Therefore we must emit variants of the
existing code that work without it, whether r12-relative (playing the
same role as MIPS's $25) in the same number of instructions, or first
retrieving PC in an i386-like manner, being careful not to clobber LR.
On 32-bit PowerPC even direct calls to IPLT entries face the same issue,
since we'd use the TOC base of the resolver, which may not be the same
as the caller, even within the same object.
Normal canonical PLTs still look broken on 64-bit PowerPC as they use
the TOC pointer register too, and similarly on 32-bit PowerPC for PIEs.
We should probably treat these cases the same as PIE on i386 (except
including PDEs for 64-bit PowerPC), where it's an error due to the use
of %ebx in PLT entries.
[9 lines not shown]
arm64/vmm: Fix vgic_v3 dropping EOI for disabled IRQs
Now that IRQs can properly be disabled by GICD_ICENABLERn, an EOI for a
disabled IRQ ends up being lost, since we don't assign it to a list
register and don't enable maintenance interrupts for such cases. As a
result, we keep the IRQ active, which stops it from ever being delivered
again (which would be true even if we supported the active and pending
state). Keep disabled but active IRQs around in list registers so we can
see the EOI having taken place in a future sync (noting that since we
already don't create list registers in active and pending state there
are no concerns with causing a disabled IRQ to be delivered).
Fixes: 47e073941f4e ("Import the kernel parts of bhyve/arm64")
MFC after: 1 week
(cherry picked from commit 123dfd378959aecc97cfc1d9b457453194d6f25b)
libllvmminimal: Fix building with LLVM < 21 on riscv64
On most architectures we end up not needing ABIBreak.cpp as, although
some of the sources here do reference EnableABIBreakingChecks (or, if
assertions are disabled, DisableABIBreakingChecks) at a source level, we
compile with -ffunction-sections and -fdata-sections, and link with
--gc-sections, and it happens to be the case that all references can be
GC'ed. However, prior to LLVM 21, the RISC-V backend did not apply
-fdata-sections to .sdata, where references to these symbols end up, and
for some files we're building with such references we end up not being
able to GC .sdata due to the other unrelated data in it, meaning that we
do in fact need to build ABIBreak.cpp.
Whilst we could make this conditional on the architecture, it's a tiny
file, and it's a bit fragile to rely on GC behaviour, so just include it
unconditionally.
Reviewed by: dim, emaste
Fixes: 770cf0a5f02d ("Fixups after llvm-project main llvmorg-21-init-19288-gface93e724f4 merge")
[4 lines not shown]
Merge commit cbf48349e3e1 from llvm-project (by Jessica Clarke):
[NFC][ELF][PPC64] Pass address not offset to writePPC64LoadAndBranch (#212275)
Every caller currently subtracts the TOC base in its argument, so move
that into common code inside writePPC64LoadAndBranch. This will also
allow a different computation to be used in some cases in a future
commit.
Note that offset is now unsigned not signed; even previously, all
arguments were uint64_t, and all uses are unsigned, so making it signed
doesn't make much sense.
MFC after: 1 week
(cherry picked from commit bcbcd7303009344dc1051e4601284620bca29be8)
arm64/vmm: Fix vgic_v3 copy paste error for writing to GICD_ICENABLERn
Otherwise we try to disable the wrong IRQ.
Fixes: 47e073941f4e ("Import the kernel parts of bhyve/arm64")
MFC after: 1 week
(cherry picked from commit 422a530c80080f2585ecefe812d609079b851fe3)
[AMDGPU][GISel] Match constrained shifts across register bank copies
The constrained shift PatFrags (csh_mask_* wrapped by cshl_/csrl_/csra_)
supply GISelPredicateCode and are imported into the GlobalISel match
table, but they never fired for a divergent shift. AMDGPURegBankLegalize
places a cross-bank COPY in two positions inside the shape they match:
- the mask constant stays in the SGPR bank, so a divergent G_AND reads
it through a COPY and the frag's imm operand is not a G_CONSTANT;
- a uniform G_AND feeding a divergent shift is copied to the VGPR bank,
so the shift's amount operand is not a G_AND.
Either way GIM_CheckOpcode rejects the rule before isUnneededShiftMask
is ever consulted, and the redundant v_and_b32 survives into the output.
Set GIIgnoreCopies so the matcher emits GIM_RecordInsnIgnoreCopies for
those operands. A frag's flags only govern how its own operands are
found, so the first position needs the flag on csh_mask_* while the
second needs it on the node holding the shift; split the masked
[17 lines not shown]
[AMDGPU] Skip s_delay_alu for WMMA C-reuse chains (#214101)
Consecutive wmma/swmmac ops accumulating into the same matrix C register
reuse the accumulator in place, so the tied srcC read is omitted and no
delay is needed. AMDGPUInsertDelayAlu did not model this and emitted an
s_delay_alu that stalls the reuse chain.
Detect a C-reuse edge (tied srcC exactly matches the previous wmma/
swmmac dest, with no intervening instruction) and skip the delay for
that operand. This applies on all wmma-capable targets (gfx11+).
[clangd][ParseHLSL] Fix register attribute source range for hover inside arguments (#212881)
Hovering on the slot identifier inside `register(t1)` (e.g. on `t1`)
previously produced no tooltip, only hovering on the `register` keyword
itself worked.
`HLSLResourceBindingAttr`'s `SourceRange` was zero-width: both the start
and end pointed to the start of the `register` keyword.
`ParseHLSLAnnotations` called `Attrs.addNew` with a single
`SourceLocation` instead of a full `SourceRange`. Since clangd's
`SelectionTree` only matches when the cursor falls inside an attribute's
range, a zero-width range never matched positions inside the argument.
Capture the closing `)` location before it's consumed in the
`AT_HLSLResourceBinding` case, and pass a full `SourceRange` (from the
attribute start to the closing paren) to `addNew`.
Fixes #212749
