[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MirageOS-devel] Fix warnings in Xen C code





On Thu, Aug 13, 2015 at 1:06 PM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
On 13 August 2015 at 17:48, Len Maxwell <len@xxxxxxxx> wrote:
>
>
> On Thu, Aug 13, 2015 at 9:02 AM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> On 13 August 2015 at 13:19, Len Maxwell <len@xxxxxxxx> wrote:
>> >
>> > On Thu, Aug 6, 2015 at 4:58 AM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>> >>
>> >> On 6 August 2015 at 00:26, Len Maxwell <len@xxxxxxxx> 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.


--
Len
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.