[dyndbg][AsmPrinter] Add tail padding attributes (#194852)
"tail-pad-to-size"="n": Pad functions up to at least 'n' bytes.
"tail-pad-value"="n": Pad using the value 'n' (default 0).
This patch is to support dynamic debugging, RFC:
https://discourse.llvm.org/t/90113
In order to transfer control from an optimized to an unoptimized function a
debugger may patch the optimized version with a jump to the unoptimized
one.
This patch adds a mechanism to ensure there's enough padding between functions
to avoid patches overwriting unrelated code. It adds padding to the end of
functions smaller then 'n' bytes.
The `.fill` directive expression was discussed here:
https://discourse.llvm.org/t/89658
See the RFC and pull request for discussions of alternative approaches.
Keep container records unless their pool was really destroyed
## Problem
The container FS attachment delegate was the only stateful-workload delegate whose `delete()` destroyed configuration: it undefined the libvirt domain and removed the `container_container` and `container_device` rows, while deliberately leaving the rootfs dataset alone. VMs and apps only stop. That made `pool.export(cascade=True, destroy=False)` — the flow that exists precisely because the pool is moving elsewhere intact — permanently orphan live storage. A container's definition, devices and idmap slice live only in SQLite, nothing on disk can rebuild them (unlike the migrated incus containers, we write no manifest), and a freed idmap slice can be reissued to another container while the surviving rootfs still carries its UID range.
`pool.dataset.delete` reached the same code with no cascade flag at all, so deleting a dataset that a container merely bind-mounted as a FILESYSTEM device destroyed the whole container. And since `query()` only reports containers in ACTIVE_STATES, the cleanup was not even coherent — it dropped the records of running containers and kept those of stopped ones.
## Solution
- **`delete()` is now stop-only**, matching the VM and apps delegates. Records are never removed from the delegate. The unconditional `etc.generate` that hung off its `for`/`else` goes with them — there was no `break` for that `else` to guard.
- **Record removal moved to a new `destroy()` step on the attachment delegate**, which `pool.export` calls once the zpool destroy has returned — the only point that can see whether the data actually went away. `delete()` still has to run first so the datasets are released, whereas discarding configuration is safe only once the data it describes is confirmed gone, and everything in between (the `pool.pre_export` hook, `kill_processes`, the destroy itself) can abort the job with the pool still fully intact. It is gated on `cascade` together with a `destroyed` flag reflecting what the export really did rather than `options['destroy']`: asking to destroy an OFFLINE pool leaves it untouched on its disks, so the requested option on its own would still have discarded records whose storage was intact. The base implementation is a no-op, since the share/task delegates already disposed of their attachments in `delete()` while the pool was still there; the container one matches on the pool its root dataset lives on and ignores runtime state, so stopped containers are cleaned up too, and a container merely bind-mounting the destroyed pool keeps its definition.
- **Containers are re-pointed at their storage when a pool is imported under a new name.** The dataset is always `<pool>/.truenas_containers/containers/<name>`, so the new location is derived rather than guessed. The remap is committed only when the old pool is genuinely gone, the derived dataset exists, and no other container claims it; each container is applied behind its own boundary so one failure cannot abort the import or block the rest.
- **`pool.reimport` no longer starts everything on the pool.** It walks the delegates in start-priority order (it was using registration order, quietly defeating the docker/apps ordering) and calls a new `start_on_import`, which containers and VMs override to honour `autostart`. Previously every stopped container and VM on the pool came up regardless.
Also documents why `storage_paths()` derives the container root from the dataset name rather than its real mountpoint — both consumers need the name-derived form, and switching to the mountpoint would silently stop matching containers on pool export and lock.
[RISCV] Lower scalar `CLMUL` to `vclmul` if `clmul` instruction not available (#212616)
The `Zbc` and `Zvbc` extensions in RISC-V are independent, thus some
hardware may support `Zvbc` (`vclmul(h)`), but not `Zbc` (`clmul(h)`).
Rather than forcing scalar `CLMUL(H)` to expand in this case, simply
insert into a vector register, use `vclmul(h)`, and extract instead.
For now, only allow this for RV64, where `clmul` and `vclmul` both
operate on the same width. RV32 has the potential for similar tricks,
but it would be more complicated, and is left as a FIXME for now.
[lldb][test] Skip the API tests a WebAssembly target cannot support (#213788)
This is the final batch of skips. Together with a handful of local
changes to LLDB and WAMR, the test suite now passes when targeting
WebAssembly. Each test has a short comment explaining why it's skipped.
[mlir][ArmSVE] move transform entry points into arm_sve namespace (NFC) (#213949)
This PR moves `populateLowerContractionToSVE*` entry points into the
`arm_sve` namespace for consistency with their Arm Neon counterparts.
[dsymutil][ARM][NFC] Require AArch64 for fat-dylib-update.test (#213836)
fat-test.arm.dylib contains armv7, armv7s, and arm64 slices, so the test
needs the AArch64 backend in addition to ARM.
[libc++] Implement P3016R6: Resolve inconsistencies in begin/end for `valarray` and braced initializer lists (#173637)
This paper is implemented as a Defect Report against C++11 and later
revisions.
- Inclusion of `<typeinfo>` in `<functional>` should be considered as a
patch to C++ TR1 (https://wg21.link/N1836), while the related
parts were merged into C++11.
- Changes of `initializer_list` should be considered as a patch to C++11
paper https://wg21.link/n2672.
- Changes of `valarray`, `std::begin`, and `std::end` and availability
of range access functions in `<valarray>` should be considered as a
patch to C++11 paper https://wg21.link/n2930.
- Inclusion of `<typeinfo>` in `<typeindex>` should be considered as a
patch to C++11 paper https://wg21.link/n2932.
- Changes of `std::cbegin`, `std::cend`, `std::rbegin`, `std::rend`,
`std::crbegin`, and `std::crend` and the inclusion of
`<initializer_list>` in `<iterator>` should be considered as a patch to
https://wg21.link/lwg2128, while LWG2128 is consistently
[23 lines not shown]