CI: install userspace build dependencies for unit tests
The unit job uses VM preparation that upgrades installed packages,
installs kernel and ZTS dependencies, and removes packaged ZFS modules.
None of that machine preparation is needed for the userspace unit build.
Share the Debian userspace build packages between the unit job and the
full VM installer, leaving the latter's other dependencies and setup in
place. Deliver the shared installer alongside the VM script when it runs
before the repository is copied into the guest.
Use the native unit target in the documented minimum-build example.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Kamil Monicz <kamil at monicz.dev>
Closes #19456
Attributor: Check for a fixpoint state with a single virtual call
Checking whether an abstract attribute is at a fixpoint took two virtual
calls, getState and isAtFixpoint. Add isStateAtFixpoint, which
StateWrapper implements with a direct call, and use it in the fixpoint
iteration.
attributor-light instruction counts (callgrind): -0.62% median over 68
llvm-test-suite TUs, the full attributor -0.70%.
Co-authored-by: Johannes Doerfert <jdoerfert.llvm at gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
NAS-145200 / 27.1.0 / Replace the TrueSearch program with truesearchd (by anodos325) (#20196)
- The `truesearch` service runs two units, `truesearchd` and
`truesearch-indexer`. Samba uses `spotlight backend = truesearch`.
truesearchd handles client requests. truesearch-indexer does the actual
file indexing and fs watching.
- Middleware writes `/etc/truesearchd/truesearch.conf` while the index
dataset is mounted. A dataset gets one `[target]` row if it holds an SMB
share with Spotlight search on or a WebShare share with search on, or if
it is mounted beneath such a share. Time Machine shares, home shares and
private datasets shares are not indexed.
- Encrypted datasets are now indexed due to changes in default index
dataset encryption posture.
- `.system/truesearchd` replaces `.system/truesearch`. On a data pool,
it is encrypted with the pwenc secret as a raw key. Middleware does not
mount a copy that is not encrypted or that the secret does not unlock,
and TrueSearch then reports that it is not mounted. A move of the system
dataset does not copy it, and the indexes are built again. It has the
properties of the tiering dataset.
[14 lines not shown]
[ThinLTO] Attach GUID to pre-existing declarations of imported declarations (#241395)
When a function is imported as a declaration, FunctionImporter creates
the declaration by hand and records the original GUID of the function as
!guid metadata, so that it can be located by GUID even if it was a
promoted local whose name no longer hashes to its GUID (e.g. by MemProf
ICP for cloning). However, if a declaration with that name already
existed in the destination module, the import was skipped entirely.
That declaration may have been created by the IRMover as a side effect
of linking an imported definition that references the function, e.g. a
vtable or a method table whose initializer references it. In that case
the declaration does not carry the original GUID, and MemProf's ThinLTO
backend cannot match the thin link's synthesized callsite record for an
indirect tail call to the promoted local target. The backend then does
not create the expected clone of the caller, while the callers of the
caller were already redirected to the clone by the thin link, resulting
in an undefined .memprof.N symbol at link time.
[3 lines not shown]
[clang][MS ABI] Use image-relative throw info on 32-bit Arm (#240571)
MSVC's runtime reads the throw information (ThrowInfo, CatchableTypeArray and
CatchableType) as offsets from the image base on every target but 32-bit x86,
and _CxxThrowException looks up the image base from the ThrowInfo. clang wrote
these tables with absolute pointers on 32-bit Arm, so a throw crashed in the
runtime there. Make them image-relative on Arm, as on 64-bit targets.
The RTTI stays absolute, as on MSVC.
Assisted-by: Claude Opus 5.5 (Anthropic)
routing: Fix buffer size in merge_nhgrps()
merge_nhgrps() sized its temporary nexthop array as twice
the existing group instead of the sum of both groups.
Fixes: dd945c6ba4ff ("routing: Implement merge of nhgrp in new multipath route")
[SLP]Fix crash on MinBW cast of callbr/invoke result vector
A demoted no-op cast node may reuse a callbr/invoke result as its
vector, and the cast for external insertelement users was then
inserted after a terminator. Insert it at the def's insertion point
(normal dest for invoke) or in the scalars' block for callbr. Reuse
a cached cast only where it dominates the user.
Fixes #241488
Pull-request: https://github.com/llvm/llvm-project/pull/241563
[VPlan] Don't narrow recipes without underlying instr to single scalars. (#241546)
narrowToSingleScalarRecipes creates the single-scalar replacement from
the underlying instruction of the recipe. Recipes created by VPlan
transforms may not have one. Skip such recipes, like
legalizeAndOptimizeInductions already does.
Fixes https://github.com/llvm/llvm-project/issues/241474
[VPlan] Compute cost of FNeg, Freeze and BitCast natively. (NFC) (#241489)
Compute the cost of replicated FNeg and Freeze recipes using
getCostForRecipeWithOpcode, like for the other unary and binary
operations, and the cost of replicated BitCast recipes like for the
other casts, instead of falling back to the legacy cost model.
Replicated recipes with these opcodes currently either have their costs
pre-computed by the legacy cost model or are single scalars with
matching costs, so no test changes.
[bazel][lldb] Run lldb Shell tests that build with clang (#240988)
Follow up to #238182. Let the Shell tests build inferiors with %clang,
%clang_host and %build, and run the ones that don't also need %lldb:
BuildScript, Expr/TestIRMemoryMap.test, two Breakpoint tests and 49 more
SymbolFile tests.
//clang finds its builtin headers relative to its resolved path in
bazel-out, but bazel stages them in clang/staging, so anything that
includes a header like stddef.h fails. lit_tools/clang is now a script
that runs //clang with -resource-dir pointing there. build.py also looks
for clang++ and clang-cl in the tools directory and otherwise falls back
to the host gcc, so add scripts with those names as well; exec -a keeps
the name, which selects clang's driver mode. Inferiors use the host's
libc and C++ standard library, as they do in CMake builds.
lit_data gains llvm-dwarfdump, which one of the SymbolFile tests uses.
The comments on the tests that are still excluded now only mention
%lldb.
[lldb-dap][ext] Use public npm registry in package-lock.json (#241559)
57f05c5ee419 (#240863) resolved yargs from an internal registry mirror,
which breaks `npm install` in the llvm/vscode-lldb CI.
[mlir][GPUToSPIRV] Preserve signed integer MMA accumulation (#241347)
gpu.subgroup_mma_compute encodes integer A/B signedness in their
component types, but uses a signless i32 accumulator with signed
semantics. Checking only isSigned() therefore omitted CSigned and
ResultSigned when lowering integer MMA operations.
OpCooperativeMatrixMulAddKHR interprets integer components as unsigned
unless the corresponding SignedComponentsKHR operand flag is present.
Treat signed and signless integer components as signed when selecting
these flags, while leaving explicitly unsigned and floating-point
components unflagged.
Update the signed i8 test to require CSigned and ResultSigned, and add
coverage for unsigned i8 inputs with a signed accumulator. Tighten the
floating-point check so unexpected signedness flags cannot match.
Assisted-by: Codex
[libc] Fix GCC allocation diagnostics and sized delete[] (#241533)
AllocChecker's operator new overloads inline malloc and aligned_alloc
while C++ forbids marking replaceable operator delete inline, causing
GCC 11+ to emit false-positive -Wmismatched-new-delete warnings at
delete sites. Hermetic tests compiled with GCC also trigger
-Wsized-deallocation and exception-specification errors in
HermeticTestUtils.cpp.
Pass -Wno-mismatched-new-delete on GCC 11+ in libc and test compile
options so AllocChecker preserves full malloc alias provenance without
inline-assembly barriers, while Clang continues checking new/delete
pairing. Mark placement operator new and all operator delete overloads
noexcept across CPP/new.h and HermeticTestUtils.cpp while adding the
missing aligned operator new and sized/aligned operator delete[]
definitions. Also align alloc_checker's direct includes with its CMake
and Bazel target dependencies.
[2 lines not shown]
DAG: Remove special case ldexp libcall recognition (#241467)
InstCombine now turns the eligible cases into the intrinsic.
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
[LLDB] Guard Process::m_instrumentation_runtimes with a mutex
This patch is the sixth part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
`Process::m_instrumentation_runtimes` can be accessed from multiple
threads. For example, a plugin can be enabled/disabled in a process
from the command thread (or from another debugger when using the
`global` domain) while `Process::ModulesDidLoad()` iterates over the
plugins on another thread, or while an SB API client calls
`Process::GetInstrumentationRuntime()`. These accesses were
unsynchronized.
Now every access to `m_instrumentation_runtimes` is guarded by the new
`m_instrumentation_runtimes_mutex`:
* `Process::Finalize()` and `Process::DidExec()` clear the map while
holding the mutex.
[13 lines not shown]
[LLDB] Keep InstrumentationRuntime plugins alive during breakpoint callbacks
This patch is the fifth part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
InstrumentationRuntime plugins passed a raw `this` pointer as the baton
for their breakpoint callbacks. Now that disabling a plugin in a process
destroys the plugin instance, a plugin could be destroyed (e.g. by
`plugin disable` running on the command thread) while one of its
breakpoint callbacks was running on another thread (e.g. the thread
handling the stop event), causing a use-after-free.
Try to partially fix this by keeping a plugin alive while the baton is being
used. Now the plugins use a baton created by
`InstrumentationRuntime::CreateBreakpointBaton()` which only holds a weak
reference to the plugin. In a callback,
`InstrumentationRuntime::GetRuntimeFromBaton()` gets a strong reference to the
plugin which keeps the plugin alive until the callback finishes. If the plugin
[13 lines not shown]
[LLDB] Support enabling/disabling InstrumentationRuntime plugins in a debug session
This patch is the fourth part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
This is a rework of an older now abandoned patch:
https://github.com/llvm/llvm-project/pull/193334
Previously enabling/disabling an instrumentation runtime plugin via the
`plugin enable/disable instrumentation-runtime.<name>` command was only
supported using the `global` domain. This only toggled the plugin's
enablement state in the PluginManager. This would affect the enablement
in newly launched processes but not in any existing processes. In
practice what this meant is that:
1. If the plugin was activated when the inferior process was launched it
could not be disabled even if requested. This meant it was impossible
to prevent LLDB from stopping at the breakpoint set by an
[106 lines not shown]
security/vuxml: FreeBSD private sqlite3 is not vulnerable
Although the FreeBSD base system does ship the vulnerable version of
sqlite3, it is only used internally as a private library. None of the
use cases in the base system is realistically vulnerable.
Approved by: so (gordon)
Discussed with: secteam
Fixes: 2d614195fc56 ("security/vuxml: Add FreeBSD (base) to the
sqlite3 entry")
[LLDB] Guard Process::m_instrumentation_runtimes with a mutex
This patch is the sixth part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
`Process::m_instrumentation_runtimes` can be accessed from multiple
threads. For example, a plugin can be enabled/disabled in a process
from the command thread (or from another debugger when using the
`global` domain) while `Process::ModulesDidLoad()` iterates over the
plugins on another thread, or while an SB API client calls
`Process::GetInstrumentationRuntime()`. These accesses were
unsynchronized.
Now every access to `m_instrumentation_runtimes` is guarded by the new
`m_instrumentation_runtimes_mutex`:
* `Process::Finalize()` and `Process::DidExec()` clear the map while
holding the mutex.
[13 lines not shown]
[LLDB] Keep InstrumentationRuntime plugins alive during breakpoint callbacks
This patch is the fifth part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
InstrumentationRuntime plugins passed a raw `this` pointer as the baton
for their breakpoint callbacks. Now that disabling a plugin in a process
destroys the plugin instance, a plugin could be destroyed (e.g. by
`plugin disable` running on the command thread) while one of its
breakpoint callbacks was running on another thread (e.g. the thread
handling the stop event), causing a use-after-free.
Try to partially fix this by keeping a plugin alive while the baton is being
used. Now the plugins use a baton created by
`InstrumentationRuntime::CreateBreakpointBaton()` which only holds a weak
reference to the plugin. In a callback,
`InstrumentationRuntime::GetRuntimeFromBaton()` gets a strong reference to the
plugin which keeps the plugin alive until the callback finishes. If the plugin
[13 lines not shown]
[LLDB] Support enabling/disabling InstrumentationRuntime plugins in a debug session
This patch is the fourth part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
This is a rework of an older now abandoned patch:
https://github.com/llvm/llvm-project/pull/193334
Previously enabling/disabling an instrumentation runtime plugin via the
`plugin enable/disable instrumentation-runtime.<name>` command was only
supported using the `global` domain. This only toggled the plugin's
enablement state in the PluginManager. This would affect the enablement
in newly launched processes but not in any existing processes. In
practice what this meant is that:
1. If the plugin was activated when the inferior process was launched it
could not be disabled even if requested. This meant it was impossible
to prevent LLDB from stopping at the breakpoint set by an
[106 lines not shown]
