No objections to this design from my side, though I can't test further on account of not having any HW with MOPS support (donations welcome :-)

I think this is because our ifunc framework does not currently support fetching hwcap2 from the second argument and we have not yet decided how we want to support that (I dimly recall having discussed this with @jrtc27 at EuroBSDcon 2024). It might be easiest to grab hwcap2 using elf_aux_info() for now.

This doesn't build for me:

I'm not sure if it is a good idea to copy the amd64 design pattern for ARM. We have ARCHLEVEL support there mainly to opt out of using SIMD, but it doesn't seem like that is salient point on AArch64.

Will there be man pages for these new calls?

... well actually, perhaps @arrowd should take this one as he also has 287642 assigned.

On it.

In D54379#1242778, @guest-charlesrocket wrote:

@guest-svmhdvn oh wait looks like I missed the line porting your patch. Now I am getting this:

/home/charlie/src/freebsd-ports/x11/ghostty/work/zig-packages/vaxis-0.5.1-BWNV_LosCQAGmCCNOLljCIw6j6-yt53tji6n6rwJ2BhS/build.zig.zon:10:14: error: package not found at '/home/charlie/src/freebsd-ports/x11/ghostty/work/zig-packages/zigimg-0.1.0-8_eo2vHnEwCIVW34Q14Ec-xUlzIoVg86-7FU2ypPtxms'
            .hash = "zigimg-0.1.0-8_eo2vHnEwCIVW34Q14Ec-xUlzIoVg86-7FU2ypPtxms",
             ^~~~
/home/charlie/src/freebsd-ports/x11/ghostty/work/zig-packages/vaxis-0.5.1-BWNV_LosCQAGmCCNOLljCIw6j6-yt53tji6n6rwJ2BhS/build.zig.zon:14:14: error: package not found at '/home/charlie/src/freebsd-ports/x11/ghostty/work/zig-packages/uucode-0.1.0-ZZjBPj96QADXyt5sqwBJUnhaDYs_qBeeKijZvlRa0eqM'
            .hash = "uucode-0.1.0-ZZjBPj96QADXyt5sqwBJUnhaDYs_qBeeKijZvlRa0eqM",

Not sure if this is zig2tuple or something else, checking.

In D54303#1241050, @markj wrote:

Approved. If this doesn't land soon, say in the next day or two, we should revert the original change until it does.

In D54104#1238790, @adamw wrote:

One question: should go:1.24 just mean go:1.24+? Do we foresee any reason that go:1.24 should bring in 1.24 when GO_VERSION == 1.25? Or would that lead to confusion?

You two have completely flipped me on the correct approach, and I'm now all-in on go.mk bringing in the right version for FreeBSD.org, not go.dev. I'm now wondering whether + should be more than just an optional feature. What do you two think?

LGTM