Illegal instruction in sysbench on Alpine 3.17+

I'm trying to repurpose an old machine, and I'm running into an illegal instruction issue with the sysbench package in recent Alpine versions. I'm aware that Alpine 3.17+ now requires SSE2 support from the processor, but this seems to be a different issue as the processor in question has SSE2.

The machine is a mid-2010 Mac Mini Server, its processor is one of these:

cpu family	: 6
model		: 23
model name	: Intel(R) Core(TM)2 Duo CPU     P8800  @ 2.66GHz
stepping	: 10
microcode	: 0xa0b
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm
vmx flags	: vnmi flexpriority tsc_offset vtpr vapic

I'm running Debian 12 on it (via a live boot) and it runs sysbench fine (albeit rather slowly).

I installed Docker to play around a bit more, and found that one of the container images I use gives an illegal instruction exception. I was able to reproduce this manually in an Alpine container. Here's the process:

docker run --rm -it alpine
apk add sysbench gdb
gdb -q sysbench
run
disassemble or disassemble /r

The result is this:

    0x56604f06 <+0>:	push   %ebp
   0x56604f07 <+1>:	mov    %esp,%ebp
   0x56604f09 <+3>:	push   %ebx
   0x56604f0a <+4>:	call   0x56602b29
   0x56604f0f <+9>:	add    $0x7bd91,%ebx
   0x56604f15 <+15>:	sub    $0x10,%esp
   0x56604f18 <+18>:	push   $0x10
   0x56604f1a <+20>:	call   0x56601240 <malloc@plt>
   0x56604f1f <+25>:	add    $0x10,%esp
   0x56604f22 <+28>:	test   %eax,%eax
   0x56604f24 <+30>:	je     0x56604f2e <new_value+40>
=> 0x56604f26 <+32>:	vpxor  %xmm0,%xmm0,%xmm0
   0x56604f2a <+36>:	vmovdqu %xmm0,(%eax)
   0x56604f2e <+40>:	mov    -0x4(%ebp),%ebx
   0x56604f31 <+43>:	leave
   0x56604f32 <+44>:	ret

The raw bytes of the vpxor instruction above are c5, f9, ef, c0. I'm kind of rusty when it comes to Intel's various instruction set extensions, but I think I am right in saying that this is a VEX prefix, from the AVX extensions, not an SSE2 extension.

Older recent versions of Alpine cause failures at different places. in alpine:3.17:

   0x000055a28d48f7c0 <+184>:	mov    %rax,0x27d7b1(%rip)        # 0x55a28d70cf78
   0x000055a28d48f7c7 <+191>:	call   0x55a28d48cbcd <sb_get_value_int>
=> 0x000055a28d48f7cc <+196>:	vmovsd 0x4f914(%rip),%xmm3        # 0x55a28d4df0e8
   0x000055a28d48f7d4 <+204>:	lea    0x5052a(%rip),%rdi        # 0x55a28d4dfd05
   0x000055a28d48f7db <+211>:	mov    %eax,%ecx

That vmovsd is c5 fb 10 1d 14 f9 04 00 so again I think this is an AVX instruction.

alpine:3.16 does not have this problem, so I'm speculating that this is down to the new requirements introduced in 3.17.

So sysbench, at least, appears to have been compiled to use AVX instructions. This could either be in error, or it could be that Alpine these days requires not only SSE2 but also AVX. I'd be interested in a clarification: if the latter, there are probably a lot of containers that just won't work for me on this machine and I'd rather know that up-front.