I've not tested this on a system that manifests the original issue due to lack of easy access last Friday, but it's straightforward, fixes build for me on MacOS, and works on example input.

All the prerequisites for this change have now landed. We'd like to get this in to reduce diffs to CheriBSD before we add support for multiple libcompat ARCHs in the same buildworld.

Rebase

Upstream accepted the first version of this patch as https://reviews.llvm.org/D126710

https://reviews.llvm.org/D126395

• Switch to building the locked version

In D35311#800370, @brooks wrote:

This seems a bit problematic in that the set of available symbols depends on the compiler building the tree. It may be that we want to generate them and emit the function without the if (lockfree(ptr) path instead.

In D35311#800371, @arichardson wrote:

Adding downstream patches is not great but I think in this case it's reasonable. Although maybe upstream would be happy with this too, I'm not sure what the supported compilers for compiler-rt are.

This seems a bit problematic in that the set of available symbols depends on the compiler building the tree. It may be that we want to generate them and emit the function without the if (lockfree(ptr) path instead.

Overall this change seems generally well contained for something that touches most syscalls. There are a few things that seem stray that I've noted.

PR with a better split https://github.com/freebsd/freebsd-src/pull/597

I agree with @jhb on the naming. I've introduced a couple following this convention in R10:28f047188492c8f2ddca66f162fd2ac9bdc170a6 and I've got another ~50 in my CheriBSD tree. That probably does require squashing this commit with D34850.

In D34761#789755, @sigsys_gmail.com wrote:

In D34761#789689, @brooks wrote:

A few thoughts about integration with syscalls.master:

• The if SYSFIL values aren't in syscalls.master they people won't remember to add them. This happened all the time with CAPENABLED annotations when it was in a separate file.

Should the per-sysfil short description comments be moved there too? It would put them right where they're needed the most. The Linuxulator could use sysfils too though (I had it working for a while but I didn't keep its syscalls.master files up-to-date as I kept rearranging the sysfils..).

I've done x86-ification patches with a split of combining that that have high level of duplication and punting the i386 version to a new x86/i386 directory where there is little commonality. I'll post them, likely as a GitHub PR since it's a bunch of mostly boring changes I want to be separate commits for revertability.

This one is perhaps the most debatable one since #warning isn't standard, but we've got plenty of unguarded uses.

We compile as for C99 so inline is supported and all modern compilers support __inline.

I can't find any instance of __NO_GNUC_VA_LIST in the world so I'd be tempted to drop it, perhaps in another commit.

typeof will even be in C23 as a literal (no _Typeof or the like)

FWIW, the system literally won't compiled without __GNUCLIKE_ASM defined due to pcpu.h

FYI, I've got a separate diff to remove the sys/cdefs.h include entirely since it's pointless.

A few thoughts about integration with syscalls.master:

• The if SYSFIL values aren't in syscalls.master they people won't remember to add them. This happened all the time with CAPENABLED annotations when it was in a separate file.
• I'm worried that there are enough values that people are just going to punt and not add any flags so this will be an ongoing maintenance burden even with integration into syscalls.master.

In D34696#786246, @jrtc27 wrote:

Relying on the include guards to avoid the need for an #else seems a bit gross... and tbh I'd rather these did get the x86 treatment, you could surely automate it

Adding powerpc as this effect powerpc64 and I can't test it (the comments about -m32 are only about amd64, powerpc64 builds without additional changes)