NAS-144928 / 27.0.0 / Read the ACL type of a path from statx (by yocalebo) (#20074)
The TrueNAS kernel reports the ACL type of a file system in
stx_attributes, STATX_ATTR_POSIXACL or STATX_ATTR_NFSV4ACL, from the
flags of the superblock that ZFS keeps current as acltype changes with
no remount. path_get_acltype probed system.posix_acl_access and then
system.nfs4_acl_xdr, two reads that each allocate in the kernel, and
took EOPNOTSUPP for a type. It is now one statx.
StatxAttr gains POSIXACL and NFSV4ACL, so filesystem.stat and
filesystem.listdir list them in attributes, and the v28_0_0 API names
them. A unit test makes a dataset of each acltype, checks the bits,
path_get_acltype and the attributes listed, changes the acltype with no
remount, and checks /proc, which keeps no ACL. It needs a kernel with
the change.
Original PR: https://github.com/truenas/middleware/pull/20073
Co-authored-by: Caleb St. John <30729806+yocalebo at users.noreply.github.com>
[clang] Remove forward and friend declarations of non-existent types (NFC) (#236009)
This patch removes forward and friend declarations of classes that are
not defined anywhere in the codebase.
Assisted-by: Antigravity
[clang] Replace PointerUnion::dyn_cast with llvm::dyn_cast_if_present (NFC) (#236007)
PointerUnion::dyn_cast has been soft-deprecated in favor of
llvm::dyn_cast and llvm::dyn_cast_if_present. This patch replaces
PointerUnion::dyn_cast with llvm::dyn_cast_if_present in
APINotesManager::findAPINotes.
Note that Readers[*Dir] is set to nullptr for the framework directory
when public or private API notes are found. If a private header is
included from a framework that only provides public API notes, Dir is
not redirected to PrivateDir, and Readers[*Dir] remains null.
This patch also adds a test case to cover that code path.
Assisted-by: Antigravity
[lld-macho] Reject incompatible arm64e object ABI markers
The CPU subtype of an arm64e object carries a pointer authentication ABI
marker. In a dynamic link, ld64 accepts only objects marked userland ABI
version 0, even on macOS and Mac Catalyst, whose executables are marked
version 1. It names any other marker as another architecture
(arm64e.old, arm64e.v1, arm64e.kernel, arm64e.kernel.v1 or unknown) and,
as with an arm64 object, ignores the file with a warning, or reports an
error with -arch_errors_fatal. This applies to archive members too.
lld linked these objects. Check the marker in the same way. ld64 accepts
unversioned and kernel-ABI objects in static links, so those links are
not checked.
Assisted-by: Claude Code
[lld-macho] Sign the arm64e TLV bootstrap pointer as ld64 does
The first word of a thread-local variable descriptor is bound to
__tlv_bootstrap, which dyld replaces with a pointer to tlv_get_addr that
TLV accesses call with blraaz. On arm64e, ld64 writes that bind as an
authenticated bind with the IA key and no diversity, although the object
asks for a plain pointer. Do the same.
Assisted-by: Claude Code
[lld-macho] Call through authenticated stubs on arm64e
ld64 calls dylib functions from arm64e code through __auth_stubs rather
than __stubs. Each stub is four instructions instead of three:
adrp x17, slot at page
add x17, x17, slot at pageoff
ldr x16, [x17]
braa x16, x17
where the slot is in __auth_got and holds a pointer that dyld signs with
the IA key, blended with the slot's address. The raw target is only ever
held in x16 and x17, so a stub never branches through an unauthenticated
pointer loaded from writable memory. Do the same: on arm64e, name the stubs
section __auth_stubs, make stubs 16 bytes, and put stub targets in
__auth_got. Fast ObjC stubs load _objc_msgSend from __auth_got and braa to
it in the same way, as ld64's do; small ones already branch to its stub.
__auth_stubs gets __stubs' place directly after __text. That is not just
[11 lines not shown]
[lld-macho] List arm64e __auth_got entries in the map file
The map file printed the entries of __got but not those of arm64e's
__auth_got, which held the targets of the stubs and the personalities.
Print them in the same way.
Assisted-by: Claude Code
[lld-macho] Sign arm64e personality pointers through __auth_got
The arm64e unwinder authenticates the personality pointers that it loads
through the GOT, from the personality array in __unwind_info and from a
CIE, against the address of their slot with the IA key. An image with an
unsigned slot crashes on its first throw. Like ld64, put these GOT entries
in __auth_got, whose pointers dyld signs that way. Other GOT references to
the same symbol keep their unsigned __got slot.
Assisted-by: Claude Code
[lld-macho] Keep differently signed arm64e data apart in ICF
Sections that differ only in the signing schema of an authenticated pointer
are not identical. Compare the schemas in ICF. This matters even without
--icf, because __cfstring sections, whose isa pointers arm64e compilers
sign, are always deduplicated.
Assisted-by: Claude Code
[lld-macho] Use ld64's chained fixups for arm64e
Authenticated pointers can only be encoded as chained fixups, so like
ld64, use them for every arm64e output: also below the deployment targets
at which lld switches other architectures to chained fixups, and when
-no_fixup_chains is given, which ld64 ignores with a warning while keeping
__mod_init_func and DYLD_CHAINED_PTR_ARM64E.
Write rebases and binds in ld64's pointer formats, with an 8-byte stride:
DYLD_CHAINED_PTR_ARM64E_USERLAND24 from the deployment targets at which
ld64 switches to it, and DYLD_CHAINED_PTR_ARM64E below them. As ld64 does,
and with its messages, reject rebase targets that the format cannot hold,
including targets below the image base, and images with more than 65535
imports in DYLD_CHAINED_PTR_ARM64E, whose binds have 16-bit ordinals.
Assisted-by: Claude Code
[llvm-objdump] Decode arm64e chained fixups
llvm-objdump --dyld-info and llvm-otool -dyld_info decoded only the
DYLD_CHAINED_PTR_64 and DYLD_CHAINED_PTR_64_OFFSET formats, and stopped
with "unsupported chained fixup pointer_format" on arm64e images.
Add the dyld_chained_ptr_arm64e_* structs of <mach-o/fixup-chains.h> to
BinaryFormat, and decode DYLD_CHAINED_PTR_ARM64E and
DYLD_CHAINED_PTR_ARM64E_USERLAND24 fixups in MachOChainedFixupEntry: an
8-byte stride, 16- or 24-bit import ordinals, 19-bit signed inline
addends, and rebase targets that are addresses in DYLD_CHAINED_PTR_ARM64E
and offsets from the image in DYLD_CHAINED_PTR_ARM64E_USERLAND24 and in
every authenticated rebase. Authenticated rebases and binds expose their
key, diversity and address diversity, which --dyld-info prints in the
div, addr and key columns that cctools' otool uses for arm64e.
The test builds its images with yaml2obj from the obj2yaml output of
images that ld64 linked from the sources in the test.
[2 lines not shown]
[lld-macho] Don't mix arm64 and arm64e objects
arm64 and arm64e share a CPU type, but as in ld64, an arm64e link ignores
arm64 objects and an arm64 link ignores arm64e objects with a warning, and
-arch_errors_fatal makes both an error. Like ld64, both also ignore
arm64e.x1 objects, which have the arm64e ABI but need a newer CPU than
arm64e. The inputs of an -arch arm64e.x1 link are not checked.
Assisted-by: Claude Code
[lld-macho] Don't merge ObjC categories for arm64e
Category merging rewrites category data without regard to the signing
schemas of the authenticated pointers in it, which produces a binary that
crashes when the runtime authenticates them. Until merging preserves the
schemas, warn about -objc_category_merging on arm64e and leave the
categories as they are.
Assisted-by: Claude Code
[lld-macho] Add an arm64e target
lld accepts -arch arm64e but links it with the arm64 target, so the output
claims to be arm64. Add an ARM64e target derived from ARM64, select it for
-arch arm64e, and mark the CPU subtype as ld64 does: CPU_SUBTYPE_ARM64E
with ptrauth ABI version 1 for macOS and Mac Catalyst executables, and
version 0 for everything else.
Assisted-by: Claude Code
[lld-macho] Link arm64e authenticated pointers
Parse ARM64_RELOC_AUTHENTICATED_POINTER, which keeps the pointer's signing
schema (key, diversity and address diversity) in its upper half, and write
it as an authenticated chained rebase or bind. Relocation stores the schema
next to a 32-bit addend, so its size stays 24 bytes.
As in ld64, accept only the extern form of the relocation and only a payload
with the authentication bit set and the reserved bits clear, store the
target of an authenticated rebase as an offset of at most 4 GiB from the
image base, put the addends of authenticated binds, which have no addend
field, in the imports table, and keep authenticated pointers in
__thread_vars signed pointers rather than offsets into the thread-local
data.
Assisted-by: Claude Code
[lld-macho][NFC] Access relocation addends through accessors (#234000)
This PR makes `Relocation` a class to make `Relocation::addend` private,
routing uses through `getAddend()` and `setAddend()`.
This was split out of #188378, as suggested in its review, and is the
first PR of the stack that replaces it. In the stack above, auth'd
pointer relocations store a signing schema alongside the addend.
No functional change intended.
Assisted-by: Codex, Claude
[MLIR][SparseTensor] Implemented LoopUseOuter and LoopUseInner heuristics for loop ordering (#232591)
This builds upon the chain of PRs ending here: #172198.
This PR introduces two new heuristics: loop-use-outer and
loop-use-inner, which prefer loops used across more distinct accesses to
be outwards or inwards, respectively.
The motivation to push such loops inwards is considering locality; more
tensors are being accessed, so theoretically multiple inputs can be
traversed in the innermost loop.
The motivation to push such loops outwards is mostly for sparse tensors.
If there are multiple sparse tensors being accessed by the same affine
index, the overhead of finding "matching indices" can be avoided across
the tighter inner loops. For dense tensors there could also be better
reuse of loaded data across the tighter inner loops as well.
I wasn't sure if I should document this reasoning somewhere else as
[3 lines not shown]
[MIR] Always print types on generic register definitions (#234846)
`getTypeToPrint` omits repeated generic types even on register
definitions. For instructions with multiple definitions sharing a type
index, such as `G_SDIVREM` and `G_FSINCOS`, this produces MIR that the
parser rejects with "generic virtual registers must have a type".
Assisted-by: GPT-6
NAS-144928 / 28.0.0-BETA.1 / Read the ACL type of a path from statx (#20073)
The TrueNAS kernel reports the ACL type of a file system in
stx_attributes, STATX_ATTR_POSIXACL or STATX_ATTR_NFSV4ACL, from the
flags of the superblock that ZFS keeps current as acltype changes with
no remount. path_get_acltype probed system.posix_acl_access and then
system.nfs4_acl_xdr, two reads that each allocate in the kernel, and
took EOPNOTSUPP for a type. It is now one statx.
StatxAttr gains POSIXACL and NFSV4ACL, so filesystem.stat and
filesystem.listdir list them in attributes, and the v28_0_0 API names
them. A unit test makes a dataset of each acltype, checks the bits,
path_get_acltype and the attributes listed, changes the acltype with no
remount, and checks /proc, which keeps no ACL. It needs a kernel with
the change.
[mlir][ODS] Include headers declaring used traits in generated declarations
While teaching at the [MLIR summer school](https://mlir-school.github.io/summer-2026/), a common confusion by students was the need to add includes for C++ constructs generated by TableGen, i.e., code they didn't even write!
This PR adds a `declaredIn` list to `Trait` that names the C++ headers declaring the trait or interface. Generated declarations now emit an `#include` for the headers of all traits and interfaces they use (including base interfaces, side
effects, `DeclareOpInterfaceMethods` and trait lists), plus the core MLIR headers every declaration needs.
This should heavily reduce the boilerplate required for new dialects.
The PR only introduces the mechanism, but does not yet override the field in any TableGen fields beyond the tests. Future work will also port this to more constructs (type and attr constraints e.g.). Another motivation is that this mechanism is more-or-less a UX prerequisite to have automatic dialect sharding and self-contained TableGen generated headers in the future.
[ARM] Add combine for vector_interleave operation (#225818)
When result's of vector_interleave operation feed to store operation it
can be combined to form structured store.
Wider type will be splitted by type legalizer and then each can
form structured store.
[Sink] Model stores when predicting the final sink target
When predicting where an instruction ends up after repeated sinking,
stop at a block containing a write that may clobber it.
