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

[MirageOS-devel] Size of MirageOS, too big now?


I'm trying to reduce the size of MirageOS so that it could run on some
resource constraint MCUs with appropriate backend implemented, where
the smaller the better.

I read the following info:
- http://anil.recoil.org/papers/2013-asplos-mirage.pdf ;(bytecode)
- https://discuss.ocaml.org/t/reducing-mirageos-image-size-using-ocamlc

And tried "-use-lto"(4.06.1+lto switch) with tweaking mirage code to
enable lto as:

For Mirage-skelton, "noop.hvt" after stripped, it's 960KB. It was 

  -rwxrwxr-x 1 ehirdoy ehirdoy 2498544 Feb 13 07:40 noop.hvt # w/o lto
  -rwxrwxr-x 1 ehirdoy ehirdoy 2271256 Feb 13 07:40 noop.hvt # stripped

  -rwxrwxr-x 1 ehirdoy ehirdoy 1124080 Feb 13 07:44 noop.hvt # w/ lto
  -rwxrwxr-x 1 ehirdoy ehirdoy 982056 Feb 13 07:44 noop.hvt  # stripped

This 982056B(960KB) look still too big even if it's a native "noop". I
heard that it used to be 500KB previously. I attached the output of
"nm" command to list all symbols in this binary. Is there something
wrong here?

Here are some questions:
(1) Why is "noop.hvt"(native w/ lto) 960KB after stripped?
(2) How can I dynamically enable "-use-lto" in Mirage build?
    Can OCAMLPARAM do? If so what to set in?
(3) Can I still build MirageOS as bytecode now?
(4) Is there any "ocamlclean" equivalent tool for native code?

Any hint would be really appreciated.

Attachment: noop.hvt.map
Description: noop.hvt.map

MirageOS-devel mailing list



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