We ought to implement this in tools/build/depend-cleanup.sh instead. I could move shm_open there first if you like.

Re-reading the extension logic, I whoops'd it again and somehow whoops'd it with shm_open. These were S...

I think this is wrong. If somebody referenced __sys_closefrom then she probably ought to get the syscall entry point still, regardless of the syscall presence in the kernel.

Also, I am not sure what is the reason to still export _closefrom.

Does this depend on a kernel config ? I.e. if there is a default kernel config without COMPAT12, do we still get SYS_freebsd12_closefrom in sys/syscall.h ?

Hmm... the problem is that if someone referenced __sys_closefrom and their kernel doesn't have COMPAT12 anymore (or yet), then closefrom is trivially ENOSYS at runtime, assuming I understand you right (i.e. that it should be point to __sys_freebsd12_closefrom instead of here)

Unsure about _closefrom; I modelled this after _shm_open still existing, but since I did that one, too, it's not clear to me whether it's really needed. I would suspect not.

As of right now, no- makesyscalls will unconditionally(*) emit SYS_freebsd12_closefrom.

(*) Cheri has some changes that lets an ABI configure a minimum compat version to honor so they can omit COMPAT_43 and FREEBSD4, or something like that, but this should be the only edge-case.

I mean, if somebody calls __sys_closefrom, then there was a reason to want the syscall wrapper and not something else from libc. If kernel does not implement the syscall, then ENOSYS/SIGSYS is deserved.

I believe we should not produce new _XXX symbols unless they are needed. One day we might clean the private version namespace.