[hannesm]

/cc @reynir @dinosaure

[dinosaure]

I'm fine with that but that's mostly mean that we drop 5.5.0 and 5.5.1 😕

[hannesm]

yes, so looking at the changes, I wouldn't understand why anyone wants 5.5.0 or 5.5.1. they've known security issues, and the patches for 5.5.2 are very small.

but if someone wants 5.5.0 or 5.5.1, they can go back to ocaml-solo5 1.3.4 :)

[dinosaure]

ok, fine for me 👍.

[hannesm]

the CI is failing:

Solo5: trap: type=#UD ec=0x0 rip=0x11b4df rsp=0x1fffff30 rflags=0x10042
Solo5: ABORT: cpu_x86_64.c:182: Fatal trap

locally on my laptop I manage to successfully use this PR to compile and run unikernels. I've no clue how to reproduce and debug this... when I locally MODE=hvt opam exec -- dune build --root example --display short I end up with a hello.exe which doesn't load with solo5 (solo5-hvt: example/_build/solo5/hello.exe: invalid executable: phdr[9].p_filesz note does not fall within valid size (0 < 12)).

any ideas?

[dinosaure]

I restarted the CI and it seems reproducible inside the CI but I can not reproduce it...

[dinosaure]

I downloaded the hello.exe built by our CI and according to rip=0x11b4df:

$ objdump -d hello.exe
...
11b4df:       c4 e1 f9 6e c8          vmovq  %rax,%xmm1
...

If we find a reference about vmovq, it seems that it requires AVX extension: https://www.felixcloutier.com/x86/movq (which should explain our trap).

[hannesm]

..and this code originates from dlmalloc.i (init_mparams / dispose_chunk); dtoa (b2d, sulp, strtod)

but why is the libnolibc.a that gets installed different from what is linked into the example hello.exe?

EDIT: actually I'm not sure about the last statement. locally on my laptop, there's no vmovq in either hello.exe nor in libnolibc.a.

[dinosaure]

I tried to search how to get informations from the given hello.exe (see this topic) and it seems that the CI compiled our hello.exe with:

$ readelf -wi hello.exe
...
    <d>   DW_AT_producer    : (indirect string, offset: 0x1ef): GNU C11 15.2.0 -D_FORTIFY_SOURCE=3 -mstack-protector-guard=global -mno-sse -mno-mmx -mno-aes -mno-avx -mno-red-zone -mtune=generic -march=x86-64-v3 -g -O2 -std=c11 -ffreestanding -fstack-protector-strong -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fzero-init-padding-bits=all
...

So we have the -mno-avx option here.

[hannesm]

some further notes: luckily the CI on the main branch (where I merged #187) fails with the same issue, so it is not 5.5.2 related.

the reported trap is #UD, and according to https://tizee.github.io/x86_ref_book_web/instruction/movq.html#protected-mode-exceptions this means: "If EM in CR0 is set. 128-bit operations will generate #UD only if OSFXSR in CR4 is 0. Execution of 128-bit instructions on a non-SSE2 capable processor (one that is MMX technology capable) will result in the instruction operating on the mm registers, not #UD." (which honestly, I don't understand).

the binary generated by CI -- I as well downloaded it -- also crashes with the same error on my laptop.

[dinosaure]

the binary generated by CI -- I as well downloaded it -- also crashes with the same error on my laptop.

Yes, I think the CI generate a bad hello.exe with bad instructions (AVX instructions). I think it's the -march=x86-64-v3 which brings AVX instructions. My last commit forces the use of -march=x86-64.

[hannesm]

And another note, when #187 was last run on CI, it was successful with gcc 13.2.0-7ubuntu1. within this PR (and the main branch), gcc 15.2.0-5ubuntu1 is used.

[dinosaure]

🎉

[hannesm]

thanks for your fix. I still have the feeling we need to rethink what architecture we want to support by default... with mirage/digestif#184 in mind, I guess we can loose quite some performance if we claim we run on any x86 machine... but I'm not sure how to move forward there, esp. since as shown here, some CI systems have only sparse extensions...

[hannesm]

force-pushed, rebased on top of #190

[hannesm]

force-pushed once more, now that solo 0.13.1 is out, to not include the march=x86-64 commit. /cc @dinosaure is this fine to merge and release, and keep the march only in solo5?