(Cc:ing the list as others may have ideas or be able to help you with diagnosing OCaml build/toolchain issues)
> [09:46] ← │ adamsteen ([email protected]) has left #mirage Oh, I didn't realise you were around at all. Sorry! I've left comments on the pkgconf issue in #226; however the more pressing problem is the trap I'm seeing on 6.3. If you can find time to look into that then we can hopefully merge when I get back (14th), or ping @djwillia / @ricarkol if things look good, they can also click the green button. My intuition is that it's more likely to be an issue with the OCaml parts of the build system and/or toolchain than ukvm itself since the C tests/ run fine... ... which is confirmed by the fact that I just tried running a tutorial/hello/hello.ukvm built on Linux using the ukvm-bin built on OpenBSD, and it works fine[*]: $ doas ./ukvm-bin ./hello.ukvm.linux | ___| __| _ \ | _ \ __ \ \__ \ ( | | ( | ) | ____/\___/ _|\___/____/ Solo5: Memory map: 512 MB addressable: Solo5: unused @ (0x0 - 0xfffff) Solo5: text @ (0x100000 - 0x1e8fff) Solo5: rodata @ (0x1e9000 - 0x220fff) Solo5: data @ (0x221000 - 0x2d0fff) Solo5: heap >= 0x2d1000 < stack < 0x20000000 2018-05-03 22:25:55 -00:00: INF [application] hello ^Cukvm-bin: Exiting on signal 2 [*]: Well, it appears to hang (or sleep forever) after the first message, but that may be due to timekeeping in general being screwed when running OpenBSD under nested KVM (which I noticed recently), could be confirmed by running on bare metal. For reference, comparing the output of the OpenBSD-built unikernel: $ doas ./ukvm-bin ./hello.ukvm | ___| __| _ \ | _ \ __ \ \__ \ ( | | ( | ) | ____/\___/ _|\___/____/ Solo5: Memory map: 512 MB addressable: Solo5: unused @ (0x0 - 0xfffff) Solo5: text @ (0x100000 - 0x21dfff) Solo5: rodata @ (0x21e000 - 0x254fff) Solo5: data @ (0x255000 - 0x4ffff) Solo5: heap >= 0x50000 < stack < 0x20000000 Solo5: trap: type=#UD ec=0x0 rip=0x1008 rsp=0x1ffffdf8 rflags=0x10002 Solo5: ABORT: cpu_x86_64.c:171: Fatal trap So, the OpenBSD-built binary is obviously wrong (bogus end of data segment, RIP looks like execution went off into never never land). I would first try if you can reproduce it yourself on OpenBSD 6.3, compare with OpenBSD-current then try and track down the cause. Aside: We should probably add some more sanity checks into the ukvm ELF loader, to refuse to load binaries with obviously bogus PHDRs. Cheers, -mato
