__ASSUME_ALIGNED could work. __builtin_assume_aligned is broadly supported so I double we even need a fall back.

I like the overall change. I've at most skimmed the makefile bits, but this seems like a move in the right direction.

In D55310#1269811, @jhb wrote:

I suspect the complexity wasn't to avoid 4 bytes per thread but more because TLS wasn't reliably working on all of our architectures when this was first written (but I could be wrong). :)

This is a lot easier to follow.

Huh, I'm surprised lld doesn't complain.

In the LLVM ports, the lines like:

_BE_LIBS_Mips=		AsmParser Disassembler
_BE_LIBS_BACKWARDS_Mips=Exegesis

Should not be removed as the Mips backend will continue to be built when default options are used and these are needed to ensure the files are handled correctly. The changes removing support from the FREEBSD and NATIVE targets are fine.

Syscall bits look good. A few comments.

In addition to ditching mips, we've since moved all our VMs to vtnet. At this point that's table stakes unless the emulator aims entirely for retro-computing support (in which case we don't care about it.)

@vexeduxr please commit with kib's suggestion

• Rebase
• Sort EF_AARCH64 before EF_ARM

drop RISC-V

Inspired by frustration caused by recent openssl manpage install bugs blocking smoke testing.

The new commit message is much better. Thanks

I don't think the commit text is specific enough about the cause. You should point to a specific combination that fails, not claim its is was macOS only (I'm fairly sure I added this due to testing cross build on ubuntu).

centralize definition

Use size_t as the fall back type

Use PTRADDR_TYPE where available

The is a no-op change before I start trickling in about a large collection of kern_ and user_ functions required to handle integer pointer ABI compat with CHERI.

With this stack of changes it's possible to (cross)build world and kernel with ptraddr_t in a system header.

This is a nice improvement over the mix of adhoc versions.

In D54939#1258282, @jhb wrote:

I suspect the old code just predates reliable TLS support in the toolchain so was using the guts of the implementation for pthread_key.

This makes me wonder why not setrlimit_type(id_t id, int /*idtype_t*/ type, int which, const struct rlimit *rlp), but it's not clear most types really want limits so it feels overall like premature generalization.

rebase

proc not prot in clnt_broadcast_resultproc_t

In D54941#1256407, @ngie wrote:

@brooks : not sure if my tree is out of date, but I found a few more references of potential concern:

% rg -l '\(resultproc_t\)' worktree/main/ | sort | sed -e 's,worktree/main/,,g'
...
usr.bin/rup/rup.c
usr.bin/rusers/rusers.c
usr.sbin/bootparamd/callbootd/callbootd.c
usr.sbin/ypbind/ypbind.c

Do those need to be changed?

In D54940#1256279, @glebius wrote:

Question on naming. I would read "resultproc" as "result process". What does "resultprot" stands for?

Alternatively one could avoid passing free to thr_keycreate, but the complexity of the thr_keycreate approach doesn't seem worth it to save sizeof(void *) of TLS storage.

NFC = "No functional change" in this context.

LGTM