In D52933#1210535, @markj wrote:

In D52933#1210529, @brooks wrote:

I'm also a little confused as to where __GNUC_PREREQ__ came from when all the references I can find online are to __GNUC_PREREQ (no trailing __).

Are you sure that's not __GNU_PREREQ?

In D52933#1210494, @markj wrote:

That would probably work too, assuming that all the versions of clang we care about have __has_builtin as well. At a glance that seems to be the case.

Could we not just swap the order of the checks in stdckdint.h so clang never evaluates __GNUC_PREREQ__? We're already requiring at least an always-false __has_builtin in the next section in cdefs.h.

@cperciva committed the same thing in 0a3792d5c5764945259333db4c66774385f01ba7

Drop riscv_clen and add CHERI__

Mention __riscv_clen. It definitly exists in CHERI LLVM, I didn't have
an easy way to check RV64Y so go with this for now.

Corrections and suggestions from @jhb

Add (planned) to CHERI architectures

Actully add previous change I guess I hadn't rebased

Address suggestions from markj and kib

FWIW, we do currently add __LP64__ to CFLAGS in bsd.cpu.mk has a hack because there's a lot of code of the form:

#ifdef __LP64__
// 64-bit stuff
#else 
// 32-bit stuff
#endif

and we haven't cleaned it all up yet. The goal here is to get people stop adding more. It is usually less wrong to write:

#ifdef __ILP32__
// 32-bit stuff
#else 
// 64-bit stuff
#endif

since much of the time a the 64-bit stuff isn't about pointer size.

Be explicit that the compiler does not define LP64 on CHERI
architectures. Don't bother mentioning ILP32 as FreeBSD will never
support 32-bit CHERI.

Revise wording around ptrdiff_t, etc use.

Attempt to approve wording around continued use of ILP32 and LP64.

In D52833#1207103, @imp wrote:

Fun. Commit message could be better at explaining why this happens with the old code

• Restore CHERI bits from D52821
• Add some words about intptr_t being a capability type

• Remove stray CHERI bits. Will reappear in D52822

In D52818#1206838, @emaste wrote:

I guess there's also 32-bit MIPS in 13 still, and this doc claims to apply to 13.0 and later unless otherwise noted. But it doesn't matter as MIPS has already been removed from all of the individual tables.

In D52818#1206819, @emaste wrote:

Is this true for 32-bit powerpc as well?

This and the commits before it in the stack are intended to start documenting CHERI as it impacts the ABI. I'll probably MFC at least the _ILP32__/__LP64__ one.

In D52334#1194932, @jrm wrote:

What am I missing?

jrm@asn /usr/src/usr.sbin/tcpdump [arcpatch-D52334_1|✔] % sudo make clean
===> libnetdissect (clean)
cd: /usr/src/usr.sbin/tcpdump/libnetdissect: No such file or directory
*** Error code 2

Stop.
make: stopped making "clean" in /usr/src/usr.sbin/tcpdump

Remove stray downstream bits

I wonder if there is somewhere we should be being shouty about the time needing to be correct?

One comment, but looks good from a syscall perspective.

Abandon in favor of dropping the default version in D51858

• Fix base flags
• Retain P_OSREL_MAP_GUARD definition

LGTM. This is about what I was going to do, except I couldn't figure out which gssapi.h to not install.

In D5650#1184327, @imp wrote:

In D5650#1184157, @brooks wrote:

This probably shouldn't land in quite this shape, but I'd really like avoid shipping FreeBSD/RISC-V+CHERI with never support symbols. There's always libc.so.16, but that might be too exciting and someone would have to organize the purge...

So the question is: is this review close enough to a good solution to keep open? Or should you steal the idea, with credit, and get on with it?

This probably shouldn't land in quite this shape, but I'd really like avoid shipping FreeBSD/RISC-V+CHERI with never support symbols. There's always libc.so.16, but that might be too exciting and someone would have to organize the purge...

Without this change, touching libsys_pic.a in the object tree had no effect. This in turn was causing bootstrap problems when the contents of _exit.pico changed in libsys.

• Make SYS_exit definition a config option rather than a special case in the script

I fear the underlying code code isn't safe. The problem is that each of the value of GEN_* is a target on its own. As a demonstrator I created a trivial makefile:

GEN=a b c d
${GEN}:
        touch ${GEN}

I you ask it to make multiple targets in parallel with something like make -j40 a b c d the generator runs more than once:

--- a ---
--- b ---
--- c ---
--- d ---
--- a ---
touch a b c d
--- b ---
touch a b c d
--- c ---
touch a b c d
--- d ---
touch a b c d

It probably works out ok in practice because it just recreates the files with the same contents, but I'm afraid adding the sed will introduce more races. I'm not sure what the correct solution is. Make doesn't really deal well with multiple outputs.