This is probably equally a bug in mirage, but raising here as it concerns only solo5.

If I compile a C source that contains, at the top level, something like

char *p = "xxx";

with the flags given by pkg-config --static --cflags ocaml-freestanding[1], and then link it in using mirage -t virtio, which passes pkg-config --variable=ldflags solo5-kernel-virtio[2] and pkg-config --static --libs mirage-solo5 ocaml-freestanding[3] to ld, the generated unikernel ends up with p == 0. I can see "xxx" in the binary, but p's value is never set to its address.

I suspect the problem is in the linker script, but so far cannot figure out how to solve it.

This becomes more interesting when the pointer is supposed to point to functions, as it breaks OCaml's custom primitive data, like zarith bignums, which in turn breaks cryptography.

[1] -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/include -ffreestanding -mno-red-zone -mno-3dnow -I/home/self/.opam/system+solo5/lib/pkgconfig/../../include/ocaml-freestanding/include -I/home/self/.opam/system+solo5/lib/pkgconfig/../../include/solo5-kernel-virtio/include

[2] -nostdlib -z max-page-size=0x1000 -static -T /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/solo5-kernel-virtio/solo5.lds /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/solo5-kernel-virtio/solo5.o

[3] /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/mirage-solo5/libsolo5camlbindings.a /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/ocaml-freestanding/libasmrun.a /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/ocaml-freestanding/libotherlibs.a /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/ocaml-freestanding/libnolibc.a /home/self/.opam/system+solo5/lib/pkgconfig/../../lib/ocaml-freestanding/libopenlibm.a