DNM: github/morello: catch up to 2023.11

[nwf-msr]

The 2023.11 ports tree no longer has llvm-localbase depend on llvm, so go ahead and install that too.

CI on this PR will make sure that it still works with 2022.12, and I'll go manually test that it works on 2023.11, too.

[nwf-msr]

Ah, well, so much for easy. CheriBSD 2023.11 does not expose old jemalloc experimental API symbols (specifically allocm, nallocm, sallocm, dallocm, rallocm). (If you want the actual failure, it's over at https://github.com/microsoft/snmalloc/actions/runs/7415212980/job/20177910989 .) Jess conveys that they have even been removed from upstream jemalloc and are kept by FreeBSD for compatibility. How should we proceed?

Tagging @davidchisnall for opinions.

[davidchisnall]

FreeBSD has backports of them because someone thought it was a good idea to make them part of the libc API. I added them in snmalloc so that my snmalloc-in-libc branch can be ABI preserving. I’m not sure why CheriBSD removed them, since I’m not sure upstream FreeBSD has that option without a libc SONAME bump (which no one wants) and doesn’t need to do it (since we have compat implementations).

The test is toggled by this line:

https://github.com/microsoft/snmalloc/blob/640cacf90ee83697d082c8fc758f0ea762e5e27a/src/test/func/jemalloc/jemalloc.cc#L19

We run it against libc on FreeBSD to make sure that our implementations of their APIs have the same behaviour as libc. We probably need an option to disable that if CheriBSD is happy breaking ABIs.

[nwf-msr]

Bah. The easy thing doesn't seem to have worked. https://github.com/microsoft/snmalloc/actions/runs/7425654462/job/20207760770