[X86] Add baseline tests exposing invalid masked folds. (#178411)
This tests exposes invalid same-mask fold.
We need prevent folding the load into an "interleave‑type instruction",
because doing so removes the double mask application, which affects the
final result of the operation. For some instructions, folding the load
is simply invalid, even if the same mask is used. I have already
prepared a patch.
Few examples
```
EVEX.128.66.0F.WIG 67 /r VPACKUSWB xmm1{k1}{z}, xmm2, xmm3/m128
A: 00010203 7F000001 80000002 DEADBEEF
E : 00000000000000010000000200000003
D: 11111111222222223333333344444444
k = 0x0400
Masked_e = 00000000000000000000000000000000 (vmovdqu8{k}{z} Masked_e E)
res1 = 00000000000000000001000000000000 (VPACKUSWB D{k}{z}, A, E)
[27 lines not shown]
security/wazuh-agent: fix syntax error in opnsense-fw active response (#5174)
Fix critical syntax error in opnsense-fw active response script that prevents IPs from being added to the __wazuh_agent_drop alias.
## Problem
The script contains invalid Python syntax - a variable assignment inside a dictionary literal:
```python
"parameters":{
unique_key = "%s-%s" % (...) # Invalid Python syntax
"keys": [unique_key]
}
```
This causes the script to fail with a SyntaxError on all 'add' commands, meaning attacking IPs are never blocked.
## Changes
- Move unique_key assignment outside dictionary literal (fixes SyntaxError)
- Fix typo: 'even' -> 'event' in error message
- Add debug logging for easier troubleshooting
[3 lines not shown]
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
powerpc: explicitly cast the timebase printfs
This is causing compilation issues on powerpc:powerpc GENERIC.
(cherry picked from commit 03e4cc9fdeb2a6445f13cd41b471927a0f722fff)
[libc++] Deprecate std::launch::any extension (#173397)
`std::launch::any` was a draft C++11 feature that was removed before the
final standard but it has remained in libc++ as an extension. This patch
marks it as deprecated and suggests using `std::launch::async |
std::launch::deferred` instead.
- Used `_LIBCPP_DEPRECATED_` to mark `std::launch::any` as deprecated
with an associated warning message recommending `std::launch::async |
std::launch::deferred` instead.
- Added a `.verify.cpp` test to validate the deprecation warning.
- Updated existing tests to avoid using the deprecated extension.
- Added note about deprecation in docs.
Fixes #173219
---------
Co-authored-by: Louis Dionne <ldionne.2 at gmail.com>
[RISCV] Add isel pattern (setlt (shl X, 32), 0) -> srliw. (#178765)
DAGCombiner sometimes turns (setlt (sext_inreg, X, i32), 0) into this
now so we need another pattern.
I tried to remove the sext_inreg pattern but it seems DAGCombiner
doesn't always do this transform. I suspect it depends on if
SimplifyDemandedBits visits the setcc. We could probably make (setlt Y,
0) call SimplifyDemandedBits on itself.
Fixes #178600.
[lldb] Add support for ScriptedFrame to provide values/variables. (#178575)
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
Related radar: rdar://165708771
powerpc: add a best-effort SMP time base sync for G5's that need it
There's no timebase freeze platform routine registered on my dual 2.3GHz
G5 PPC970FX Apple PowerMac.
For platforms without an explicit timebase freeze/unfreeze, we'll have to
make do with what we have - which for now is an explicit hand-crafted
spinlock/rendezvous method.
* For existing platforms, they'll still continue to clock freeze /
rendezvous; albeit with some stronger atomic bits now (from jhibbits@.)
* Instead of the fallback being "no timesync", implement a
best-effort one which does a similar rendezvous barrier between
BSP and APs, but instead of freeze/unfreeze the first instruction
after the CPUs all register they're ready is to set the timebase.
This has resulted in many reboots of my Powermac G5 dual-socket device
correctly starting and running in SMP mode.
[4 lines not shown]
powerpc: fix release image building for Apple partitions
awk changed somewhere between 14 and 15 and it stopped accepting
a hexadecimal number as its input - it will always return 0.
This results in a very badly written apple boot block.
So just remove it; do the math in shell.
PR: kern/292341
Differential Revision: https://reviews.freebsd.org/D54639
Reviewed by: imp
MFC after: 1 week
(cherry picked from commit 7afa03963c448a14b1735a10eaf84941b0b74862)
powerpc: put the isync inside the TD_LOCK() checking loop
Fix a narrow window where the lock is unlocked but the checking CPU
hasn't flushed things appropriately.
Inside this window the CPU inside cpu_switch() will loop forever thinking
the destination thread is still blocked/locked even though it is not.
This manifests as the system hanging after starting all APs.
I've seen this reliably trigger in qemu-system-ppc64 running power9 pseries
guests; the more CPUs the more likely it triggers at boot.
PR: kern/292167
Differential Revision: https://reviews.freebsd.org/D54478
Reviewed by: jhibbits
MFC after: 1 week
Relnotes: yes
(cherry picked from commit 8df2e542146801fd01675e56724eaa567d04c209)
powerpc: add a best-effort SMP time base sync for G5's that need it
There's no timebase freeze platform routine registered on my dual 2.3GHz
G5 PPC970FX Apple PowerMac.
For platforms without an explicit timebase freeze/unfreeze, we'll have to
make do with what we have - which for now is an explicit hand-crafted
spinlock/rendezvous method.
* For existing platforms, they'll still continue to clock freeze /
rendezvous; albeit with some stronger atomic bits now (from jhibbits@.)
* Instead of the fallback being "no timesync", implement a
best-effort one which does a similar rendezvous barrier between
BSP and APs, but instead of freeze/unfreeze the first instruction
after the CPUs all register they're ready is to set the timebase.
This has resulted in many reboots of my Powermac G5 dual-socket device
correctly starting and running in SMP mode.
[4 lines not shown]
