[X86] Enable sibcalls through 32-bit function pointers (#176518)
x86_32 is pretty dead, but I think this was an unintended consequence of
a change I reviewed and landed back in 2015 (80956a01425ee0), and the
code didn't match the comments, so it's worth fixing.
I added an ExternalSymbol case to cover sin at PLT, which has test
coverage.
I also combined the 3 relevant tests and made them use CHECK-LABEL, so
now this test uses LLVM test best practices circa 2018.
aq: remove from NOTES; it's unfortunately amd64 only
Unfortunately the aq driver is using readl/writel calls instead
of bus space routines.
This broke, well, everything else.
Fixes: c75eff16ef54aaae7b5dc52ed894cc73a855f469
Merge tag 'block-6.19-20260116' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- NVMe pull request via Keith:
- Device quirk to disable faulty temperature (Ilikara)
- TCP target null pointer fix from bad host protocol usage (Shivam)
- Add apple,t8103-nvme-ans2 as a compatible apple controller
(Janne)
- FC tagset leak fix (Chaitanya)
- TCP socket deadlock fix (Hannes)
- Target name buffer overrun fix (Shin'ichiro)
- Fix for an underflow for rnbd during device unmap
- Zero the non-PI part of the auto integrity buffer
- Fix for a configfs memory leak in the null block driver
[11 lines not shown]
Merge tag 'io_uring-6.19-20260116' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull io_uring fix from Jens Axboe:
"Just a single fix moving local task_work inside the cancelation loop,
rather than only before cancelations.
If any cancelations generate task_work, we do need to re-run it"
* tag 'io_uring-6.19-20260116' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux:
io_uring: move local task_work in exit cancel loop
[lldb] Enable chaining multiple scripted frame providers per thread (#172849)
This patch allows threads to have multiple SyntheticFrameProviderSP
instances that chain together sequentially. Each provider receives the
output of the previous provider as input, creating a transformation
pipeline.
It changes `Thread::m_frame_provider_sp` to a vector, adds provider
parameter to SyntheticStackFrameList to avoid calling back into
`Thread::GetFrameProvider()` during frame fetching, updated
`LoadScriptedFrameProvider()` to chain providers by wrapping each
previous provider's output in a `SyntheticStackFrameList` for the next
provider and finally, loads ALL matching providers in priority order
instead of just the first one.
The chaining works as follows:
```
Real Unwinder Frames
↓
[11 lines not shown]
powerpc: Add ISA 2.06 sub-word atomic set/clear
Add atomic_set/clear_short/char for doing 8-bit and 16-bit operations
more efficiently on "newer" architectures (POWER7 and later).
Piggybacks on b31abc95eb.
ipfw: refactor how we store bpf tap points
Make the tap database belong to ip_fw_chain, but leave the default "ipfw0"
tap per-vnet. This is only slightly better than keeping the database per-
vnet, as the bpf name space is per-vnet. However, we yet have only single
ipfw chain. Whenever multiple chains will coexist, this needs to be
addressed.
Require the chain lock to make modifications to the database.
Move tap allocation to a later ruleset build stage, when all rule numbers
are known already. This fixes a panic introduced by 3daae1ac1d82.
Fixes: 3daae1ac1d82ecdcd855101bab5206e914b12350
ipfw: in a vnet destructor use NET_EPOCH_WAIT()
The lock grab & drop predates epoch(9) introduction to the network
stack and it doesn't provide a true guarantee that all threads that
may use ipfw configuration have finished. Also the lock prevented
from sleepable operations when freeing the rules.
spi: "-S" option for continuous stream from standard input to bus
created to allow addressable leds to be driven by abusing spi bus as waveform generator. this might have other uses for similar "permanent" spi transfers
Differential Revision: https://reviews.freebsd.org/D54734
Reviewed by: adrian
[RFC][Clang][AMDGPU] Emit only delta target-features to reduce IR bloat
Currently, AMDGPU functions have `target-features` attribute populated with all default features for the target GPU. This is redundant because the backend can derive these defaults from the `target-cpu` attribute via `AMDGPUTargetMachine::getFeatureString()`.
In this PR, for AMDGPU targets only:
- Functions without explicit target attributes no longer emit `target-features`
- Functions with `__attribute__((target(...)))` or `-target-feature` emit only features that differ from the target's defaults (delta)
The backend already handles missing `target-features` correctly by falling back to the TargetMachine's defaults.
A new cc1 flag `-famdgpu-emit-full-target-features` is added to emit full features when needed.
Example:
Before:
```llvm
attributes #0 = { "target-cpu"="gfx90a" "target-features"="+16-bit-insts,+atomic-buffer-global-pk-add-f16-insts,+atomic-fadd-rtn-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,..." }
[13 lines not shown]
vm/swap_pager.c: silence compiler warning
Initialize pindex in swap_pager_getpages_locked() before the loop
actually calculating it by skipping bogus pages. Compiler is worried
that loop might never assign to it, which actually cannot happen.
Sponsored by: The FreeBSD Foundation
Fixes: d198ad51ea73bbb162336923a387f52b0b1c1f1d
MFC after: 1 week
[CIR] Upstream support co_return of values from co_await (#173174)
This PR adds support for returning the result of a `co_await` via
`co_return`. A new variable, `__coawait_resume_rval`, is introduced to
store the returned value.
[NFC][win] Use an enum for the cfguard module flag (#176461)
Currently the `cfguard` module flag can be set to 1 (emit tables only,
no checks) or 2 (emit tables and checks).
This change formalizes that definition by moving these values into an
enum, instead of just having them documented in comments.
Split out from #176276
