__sym_compat is also used in:
lib/libthr/thread/thr_sem.c
lib/libthread_db/thread_db.c
so we'd need access to the per-arch minimums and the MK_SYMVER disable in their Makefiles too.

Maybe we can set ${LIB_MIN_DEFAULT} somewhere in share/mk and just add CFLAGS+=-DLIB_MIN_DEFAULT=${LIB_MIN_DEFAULT} to the three Makefiles

See also D5601, which addresses this for a few FreeBSD 7 compat functions on AArch64.

The one other thing that needs to be done is to filter the set of syscall stubs. Probyle with something in lib/libc/sys/Makefile.inc like:

.if ${ARCH_LIB_MIN_COMPAT} > 4
MIASM:=        ${MIASM:Nfreebsd4_*}
.endif
.if ${ARCH_LIB_MIN_COMPAT} > 6
MIASM:=        ${MIASM:Nfreebsd6_*}
.endif
# There are no COMPAT5 syscalls
.if ${ARCH_LIB_MIN_COMPAT} > 7
MIASM:=        ${MIASM:Nfreebsd7_*}
.endif

I'm probably wrong. It's a bit confusing.

Why do we need this ?

It adds significant complications IMO, while the result is slightly less versions of some symbols exported.

In D5650#120967, @kib wrote:

Why do we need this ?

It adds significant complications IMO, while the result is slightly less versions of some symbols exported.

I don't think it's a significant complication, but in any case I extended what I had done for SYMVER_COMPAT as it conflicted with what Brooks started in D5601.

In D5650#120969, @emaste wrote:

In D5650#120967, @kib wrote:

Why do we need this ?

It adds significant complications IMO, while the result is slightly less versions of some symbols exported.

I don't think it's a significant complication, but in any case I extended what I had done for SYMVER_COMPAT as it conflicted with what Brooks started in D5601.

My motivation is to avoid shipping compatibility bits in platforms that don't need them. I started to run into this with CheriABI, but it also applies to arm64 and riscv. One could argue for not removing bogus compat bit from releases we've already shipped, but let's not add them to new ones. The added complexity here isn't significant compared to libc as a whole.

I still do not like it, and probably I can argue why. Suppose that in 11 we changed the ABI of the symbol read. Then we would get read@@FBSD_1.4 (the default version) and read@FBSD_1.0 (compat shims). What should be N in LIB_MIN_COMPAT <= N check ? Now, suppose that the change is merged to stable/10 and stable/9. Does it affect code in HEAD ?

In fact, this hack is ugly demonstration of our invalid use of symver. The mechanism was designed for very much different use. It was supposed that a new version namespace is created when any symbol is added or ABI of a symbol changes.

In D5650#123571, @kib wrote:

I still do not like it, and probably I can argue why. Suppose that in 11 we changed the ABI of the symbol read. Then we would get read@@FBSD_1.4 (the default version) and read@FBSD_1.0 (compat shims). What should be N in LIB_MIN_COMPAT <= N check ?

In light of your comment I think some of the tests in the review are incorrect.

In your case it should be 11: if compat for any FreeBSD < 11 is needed, read@FBSD_1.0 must be provided.

Add @jhb (as the author of one of the compat blocks)

In D5650#123942, @emaste wrote:

In D5650#123571, @kib wrote:

I still do not like it, and probably I can argue why. Suppose that in 11 we changed the ABI of the symbol read. Then we would get read@@FBSD_1.4 (the default version) and read@FBSD_1.0 (compat shims). What should be N in LIB_MIN_COMPAT <= N check ?

In light of your comment I think some of the tests in the review are incorrect.

In your case it should be 11: if compat for any FreeBSD < 11 is needed, read@FBSD_1.0 must be provided.

IMO this is still wrong. For LIB_MIN_COMPAT 10 you would not get read@FBSD_1.0.

My opinion is that this approach is not workable. The only possible way to save the patch is to offer a binary knob, either we provide whole symver-ed universe, or we only export default versions. In the example, it would be only exporting read@@FBSD_1.4.

In D5650#123950, @kib wrote:

In D5650#123942, @emaste wrote:

In D5650#123571, @kib wrote:

I still do not like it, and probably I can argue why. Suppose that in 11 we changed the ABI of the symbol read. Then we would get read@@FBSD_1.4 (the default version) and read@FBSD_1.0 (compat shims). What should be N in LIB_MIN_COMPAT <= N check ?

In light of your comment I think some of the tests in the review are incorrect.

In your case it should be 11: if compat for any FreeBSD < 11 is needed, read@FBSD_1.0 must be provided.

IMO this is still wrong. For LIB_MIN_COMPAT 10 you would not get read@FBSD_1.0.

I don't follow: in your read example we'd have:

#if LIB_MIN_COMPAT < 11
__sym_compat(read, old_read_compat_fn, FBSD_1.0);
#endif

No FreeBSD/arm64 and FreeBSD/riscv release exists with a read@FBSD_1.0 and they now don't get the compat sym. Every other architecture has LIB_MIN_COMPAT set to 10 or lower, and so includes read@FBSD_1.0.