On Thu, Aug 13, 2015 at 1:06 PM, Thomas Leonard <[email protected]> wrote:
> On 13 August 2015 at 17:48, Len Maxwell <[email protected]> wrote: > > > > > > On Thu, Aug 13, 2015 at 9:02 AM, Thomas Leonard <[email protected]> > wrote: > >> > >> On 13 August 2015 at 13:19, Len Maxwell <[email protected]> wrote: > >> > > >> > On Thu, Aug 6, 2015 at 4:58 AM, Thomas Leonard <[email protected]> > wrote: > >> >> > >> >> On 6 August 2015 at 00:26, Len Maxwell <[email protected]> wrote: > >> >> > > >> >> > Hi, > >> >> > > >> >> > After working with minios-xen a bit, I thought I could help with > this > >> >> > pioneer project. There seem to be significantly fewer C warnings > >> >> > than > >> >> > the > >> >> > last time I looked (months ago). > >> >> > >> >> That would be very useful! > >> >> > >> > > >> > Hi, > >> > > >> > If I start from mirage-platform master (@ 94f01d), and make this > change > >> > to > >> > xen-posix/include/stdio.h: > >> > > >> > -#define fprintf(x,rest...) printk(rest) > >> > +int fprintf(FILE *stream, const char *format, ...) __THROW > >> > __attribute__((__format__(__printf__,2,3))); > >> > > >> > ...it should eliminate a missing prototype warning for printk in > >> > xen-ocaml. > >> > The package builds OK, but produces link errors when I try to make a > >> > unikernel: > >> > > >> > $ make clean && make > >> > [ ... ] > >> > ld -d -static -nostdlib \ > >> > _build/main.native.o \ > >> > -L/opt/ml/opam/4.02.1/lib/io-page -lio_page_xen_stubs \ > >> > $(pkg-config --static --libs mirage-xen) \ > >> > /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc.a \ > >> > -o mir-console.xen > >> > > >> > > /opt/ml/opam/4.02.1/lib/pkgconfig/../../lib/mirage-xen-ocaml/libxenasmrun.a(fail.o): > >> > In function `caml_array_bound_error': > >> > fail.c:(.text+0x2c8): undefined reference to `fwrite' > >> > > >> > > /opt/ml/opam/4.02.1/lib/pkgconfig/../../lib/mirage-xen-ocaml/libxenasmrun.a(misc.o): > >> > In function `caml_fatal_error': > >> > misc.c:(.text+0x42): undefined reference to `fputs' > >> > > >> > > /opt/ml/opam/4.02.1/lib/pkgconfig/../../lib/mirage-xen-ocaml/libxenasmrun.a(parsing.o): > >> > In function `caml_parse_engine': > >> > parsing.c:(.text+0x225): undefined reference to `fputs' > >> > parsing.c:(.text+0x258): undefined reference to `fputc' > >> > parsing.c:(.text+0x273): undefined reference to `fwrite' > >> > parsing.c:(.text+0x420): undefined reference to `fwrite' > >> > parsing.c:(.text+0x46b): undefined reference to `fwrite' > >> > Makefile:34: recipe for target 'build' failed > >> > make: *** [build] Error 1 > >> > > >> > > >> > Each of these caml_ functions calls fprintf. fprintf is implemented > in > >> > xen-posix/src/mini_libc.c, but it does not use fwrite/fputs/fputc, > it's > >> > just > >> > a wrapper for mini-os print(). > >> > > >> > How do I find out where these undefined references are coming from? > >> > >> Most likely, the C compiler is optimising the calls to fprintf and > >> replacing them with calls to the other functions. > >> > > > > Adding `-fno-builtin` to the xen-ocaml build resolves this. > > > > Without this flag, gcc makes assumptions about the > semantics/implementation > > of standard library functions. In this case, as you suggest, it is > inlining > > calls to fprintf using its own built-in implementation instead of > > mini_libc's. Very interesting. > > > > Not sure how this affects other parts of xen-ocaml; it can be made more > > specific with `-fno-builtin-fprintf`. > > Well, this isn't a bad optimisation (although it doesn't really matter > for Mirage, since we normally use our own console). We'd just have to > provide implementations for fputs, etc. > > Now I understand why fprintf was a macro pointing to printk -- it seems to defeat the builtin inlining and saves us implementing fputs, etc. in order to get diagnostic output from the OCaml runtime. The mini-os print/printk does a sprintf to a buffer and sends that out via the console ring. Enabling -fno-builtin across xen-ocaml could hurt performance. From [1]: "GCC normally generates special code to handle certain built-in functions more efficiently; for instance, calls to alloca may become single instructions which adjust the stack directly, and calls to memcpy may become inline copy loops." I'll find another way to clean up the warnings. Thanks. [1]: https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/C-Dialect-Options.html#C-Dialect-Options -- Len
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
