[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]
[NFC][LLDB] Add Debugger::Debuggers() locking iterable (#238463)
This patch is the third part in a patch series that will allow
enabling/disabling InstrumentationRuntime plugins in a running debug
session.
This patch adds a `Debugger::Debuggers()` static method that returns a
`LockingAdaptedIterable` over the global debugger list. This follows the
existing pattern used by other LLDB collections (e.g.
`TargetList::Targets()`).
Assisted-by: Claude Code
[Hexagon] Add HLX driver checks, intrinsic header and Sema diagnostics (#241435)
- Driver: report an error for -mhlx and -mno-hlx on CPUs older than v85,
which do not have HLX (they enabled the HLX feature and defined the
__HLX__ macros), and pass -mhlx to the assembler when HLX is enabled and
the integrated assembler is not used.
- Headers: add hlx_hexagon_protos.h with the Q6_* macros for the V85 HLX
builtins, include it from hexagon_protos.h when HLX is enabled, and
define the HLX_Vector and HLX_VectorPair types in hexagon_types.h.
- Sema: HLX vectors can only be local variables, and there are no
instructions for element access or vector pair loads and stores. When
HLX is enabled, reject global, static and variable sized objects of HLX
types, struct, union and class members of HLX types, subscripts of HLX
vectors, and dereferences of HLX_VectorPair pointers.
Co-authored-by: Adarsha Regmi <aregmi at qti.qualcomm.com>
Co-authored-by: Alexey Karyakin <akaryaki at qti.qualcomm.com>
Co-authored-by: Ankit Aggarwal <aankit at qti.qualcomm.com>
Co-authored-by: Ikhlas Ajbar <iajbar at qti.qualcomm.com>
[10 lines not shown]
[CodeGen] Stop claiming setPreservesAll() in BasicBlockPathCloning (#241026)
BasicBlockPathCloning clones basic blocks and redirects CFG edges, which
invalidates Machine-CFG analyses (such as MachineDominatorTree,
MachineLoopInfo, and MachineBlockFrequencyInfo). Drop
AU.setPreservesAll() and explicitly preserve only MachineBlockHashInfo
(which intentionally records pre-cloning block hashes for downstream
matching and BB-hash emission, though support for
MachineBasicBlockMatchingAndInference with cloning is not ready yet),
relying on MachineFunctionPass::getAnalysisUsage() for MachineModuleInfo
and IR analyses.
[SLP]Clear analysis cache when the replaced scalars are erased
The horizontal reduction and the packed aggregate paths rewrite the IR
outside of the tree vectorization, but the cached pointer distances were
dropped only after the tree vectorization. A reduction folding a GEP
index left a stale failed distance for one pointer order while the other
order succeeded, and the external store users reordering dereferenced it.
Fixes #241484
Pull-request: https://github.com/llvm/llvm-project/pull/241547
[ThinLTO] Add CFI function lists to the textual summary format (#240966)
Print and parse the names of the functions with CFI jump table entries
recorded in a combined summary index (cfiFunctionDefs and
cfiFunctionDecls), along with the GUIDs that ThinLTO uses for them, as
summary entries:
^N = cfiFunctionDefs: ((guid: G, name: "f"), ...)
^N = cfiFunctionDecls: ((guid: G, name: "g"), ...)
These follow the typeidCompatibleVTable entries and precede the flags
and blockcount entries, so the assembler and disassembler round trip a
combined index written by the thin link, and tests can describe a
distributed ThinLTO index for a module built with CFI (which
LowerTypeTests and other backend passes consult) without running a thin
link.
Assisted-by: Gemini
[ThinLTO] Support importing of indirect call target declarations (#241431)
Add support for importing declarations of all indirect call targets with
a hotness at least as high as that specified in the (default hot)
-import-declaration-for-indirect-calls-min-hotness, when the definition
is not being imported. This will facilitate more ICP when enabling
-icp-allow-decls.
Assisted-by: Gemini
ssh: use defaultkey sentinel for ML-DSA-44 default host key
servconf_add_hostkey() compares its file argument to defaultkey by
pointer to skip an unreadable default key; the ML-DSA-44 entry passed
the "[default]" literal, so the skip (and the "No host key files found"
fallback) never applied to it.
MFC after: 1 week
Reviewed by: emaste
Fixes: bb5c77e9d281 ("OpenSSH: Update to 10.4p1")
Differential Revision: https://reviews.freebsd.org/D60922
(cherry picked from commit 2d6f961164e4ab7e823972336dc9cfaae6a88ed8)
[SLP]Release all lanes of a repeated copyable element in scheduling
A copyable element in several lanes of one node may sit in different
operand columns per lane. Scheduling released only the first lane, and
the chain self-use check looked at one lane, so a direct use from
another lane kept the operand unscheduled.
Fixes #241483
Pull-request: https://github.com/llvm/llvm-project/pull/241539
[LV] Add tests for fmaxnum reduction with ALM tail folding (NFC). (#241522)
Add tests for FMaxNum reductions with tail folding using the
active-lane-mask for control flow. Currently mis-compiled.
Keep the local key where a raw receive brings a foreign one
A raw receive writes the DSL Crypto Key from the stream over the one on
disk but leaves the encryption root it is filed under alone. The key in
the stream is wrapped by the wrapping key of the sender's encryption
root, so this only holds together for as long as ours is the same one.
Where the receiving filesystem inherits from a root with a wrapping key
of its own, which is what a replica has once 'zfs change-key -i' hands
it to a locally keyed dataset, the wrapped master key on disk becomes
the sender's while the root it is filed under is still ours, and nothing
on the pool can unwrap it. The unwrapped key stays cached until it is
unloaded, so the receive and everything after it look fine; the next
'zfs load-key' loads the root happily and the filesystem then refuses to
mount with EACCES. Getting the data back takes the sending pool's
wrapping key and a hand built encryption hierarchy, which is why
reporters have ended up rebuilding their backups instead.
The keyformat, salt and iteration count travel with the key and describe
the wrapping key it was wrapped with, so where the receiving filesystem
[30 lines not shown]
Thread Safety Analysis: Carry a loop-checked try-acquire result out of the loop
A loop's exit edges were computed from the head's exit set as analyzed on
the first iteration, before the body's try-acquire result existed. An
iteration that acquires the capability and keeps the result -- the loop
checks it, so the loop join says nothing -- therefore left the loop
invisibly: neither the code after the loop nor the end of the function
saw the possible hold.
The back-edge patch that already carried a released result into those
sealed exit sets now carries such a result too. The code after the loop
is read against the possibility: `if (ok) mu.Unlock();` resolves it and
is clean, a bare release is "may not be held" rather than "was not
held", a blocking acquire is "may already be held", and where nothing
resolves it, -Wthread-safety-beta reports the leak at the end of the
function. The first three are plain -Wthread-safety: the patch is not
beta-gated, and a loop that may leave a capability held is a fact about
the code, not about a diagnostic mode. Two shapes in the existing tests
move that way, and one C++ test gains the beta report.
[40 lines not shown]
Thread Safety Analysis: Track a cross-kind try-acquire as one try fact
per kind
A call promising a capability exclusively on one outcome and shared on
another (`int TryLockCross() TRY_ACQUIRE(2, mu) TRY_ACQUIRE_SHARED(0, mu)`,
kept conditional because the codes do not cover an int result's domain)
tracked one conditional try fact of the weaker kind: a try fact carries
one kind, and the outcome that decides which attribute applies is only
known per edge. The edge promising the exclusive hold therefore granted
only a shared one, and an exclusive write under it was diagnosed.
A try fact is identified by its capability, its originating call and its
lock kind (TryFactEntry), so a call promising both kinds can have one of
each: handleCall() creates one try fact per kind the call promises the
capability in, and each resolves by its own kind's attributes. Everything
the resolution reads is keyed by kind for that: getCapProfile() takes the
kind and reads only that kind's polarity groups, and the exact codes and
any-nonzero promises the record keeps are tagged with the kind that made
them -- reading across the kinds granted one kind's hold on the edge where
[47 lines not shown]
Thread Safety Analysis: Bound a loop's checked results by dominance
A try-acquire whose result is branched on somewhere in a loop is not
reported unchecked at that loop's join: the loop checks it, on this
iteration or the next. Which blocks count as being in the loop was
decided by two different walks. The injection bounded its backward walk
from the latch by the blocks the head reaches forwards; the
checked-result scan did not bound it at all, so a goto into the body let
it walk out of the loop and collect a check made before the jump. That
is now one walk, collectNaturalLoop(), which checkBackEdges() runs once
for both phases, and its bound is dominance.
Dominance is the textbook bound, and the only one that survives nesting:
forward reachability from the head runs round an enclosing loop's back
edge and reaches the pre-loop blocks again, so for any loop inside
another cycle it excluded nothing. It is also what makes sharing the
walk affordable. Recomputing the head's forward reach costs the whole
function per back edge; clang::CFGDomTree is built once per function, on
demand, and answers in constant time. On N sequential `while` loops
[35 lines not shown]
Thread Safety Analysis: Split runAnalysis() into its phases [NFC]
runAnalysis() had grown past four hundred lines around the try-acquire
machinery. Its phases are now functions: addDeclaredLocksets() builds
the initial and expected-exit locksets from the function's attributes
(and says which functions the analysis skips), joinPredecessors()
computes a block's entry set from its predecessors, including the
infeasible-edge and coverage-only handling, visitBlock() walks the
block's elements, and checkBackEdges() compares each back edge against
its loop head and patches the loop's exit sets. The block loop itself
is the phase sequence.
injectLoopReleasedTryFacts() splits around its own natural-loop walk:
collectInjectableTryFacts() reads the release evidence out of the
latch's exit set, collectNaturalLoop() is the walk -- backwards from the
latch, bounded by what the head reaches forwards, so a second entry into
the body cannot let it escape the loop -- and patchLoopExitSets() writes
the evidence into the exit sets the loop's exit edges are computed from.
checkBackEdges() walks only when the latch carries evidence to patch, as
[36 lines not shown]
Thread Safety Analysis: Resolve try-acquire results by exact value, not
just truthiness
The attributes' success values, the branch conditions on the result,
and the resolution between them all collapsed to truthiness, which is
unsound in both directions for attributes keying distinct capabilities
to integer codes:
int trylock_codes() TRY_ACQUIRE(1, mu1) TRY_ACQUIRE(2, mu2);
`if (trylock_codes() == 2)` silently accepted uses of mu1 in its body
("truthy" promoted it too, though a result of 2 proves mu1 was never
acquired), and the other edge of `== 1` read as "result falsy", wrongly
removing mu2's fact.
Design details:
* Recording: a truthy success value keys the acquisition to that exact
result value (ExactCodes), computed by the constant evaluator so that
[110 lines not shown]
Thread Safety Analysis: Demote same-origin joins silently
A join can bring together two outcomes of one try-acquire: the hold its
success proved on one path and the record of its failure on the other.
Both sides denote "held iff the call's result", so their join is the
call's conditional try fact, and diagnosing a lost hold there reports a
loss that did not happen. intersectAndWarn() now demotes such
same-origin joins to that conditional try fact instead, silently. These
are the same-origin cells of the try fact lattice (Conditional meeting
ProvedNotHeld, ProvedHeld meeting ProvedNotHeld, and at an unsealed loop
join Conditional meeting ProvedHeld), which the join had so far refused:
a policy gate now opens them.
Design details:
* One predicate decides how a hold survives a join (holdDemotion): the
terminator rebranches on the call that proved it, so the outgoing
edges re-resolve it -- unless that call's stale result on the other
side vetoes the premise -- or else the other side carries the call's
[88 lines not shown]
Thread Safety Analysis: Resolve try-acquire results merged by a
conditional operator
A non-void `?:` on a try-acquire result used to pin it unresolved
wholesale: the branch was never honored, and only a both-arms-constant
value (`ok ? 1 : 0`) could be decoded at a later branch. The body of
`if (mu.TryLock() ? use() : false)` warned although a truthy value
proves the lock is held, and the GNU form `ok ?: 0` was not decoded at
all. Now the decode computes what the merged value determines about
the result, arm by arm, and the `?:` terminator itself is always
honored as a branch.
Design details:
* With both arms constant, the value the condition selects is one of
them: its magnitude is the arm's, so exact values are never applied
to the result (a new ValueMerged flag clears ValueIsResult), while
what the branch asks of that value decides the condition. A
comparison against an arm's own constant is satisfied exactly when
[89 lines not shown]
Thread Safety Analysis: Resolve branches on stored try-acquire results
through merges and phis
The common guard pattern
bool ok = false;
if (cond)
ok = mu.TryLock();
if (ok) { ... mu.Unlock(); }
(and the spin loop `while (!ok) ok = mu.TryLock();`) was unresolvable:
the local-variable map discarded the merged definition of `ok`, so the
branch on it did not count as checking the result, drawing the beta
"unchecked result" warning at the very check plus a spurious release
warning inside the guarded region. The map now records such merges as
two-operand phi definitions, and the decode resolves the ones whose
value still identifies the call's result.
Design details:
[124 lines not shown]
