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

Re: [MirageOS-devel] TLS on Xen status

On 17 December 2014 at 14:41, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 17 Dec 2014, at 06:29, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>> The TLS work requires ctypes and zarith to run on Xen. I now have
>> ctypes building with Xen support, but zarith is more difficult.
>> Hannes previously got it to work here:
>> http://lists.xenproject.org/archives/html/mirageos-devel/2014-09/msg00100.html
>> However, this was compiling against the local (e.g. Linux) headers,
>> not the Mini-OS ones. It seems to work, but it's obviously not ideal.
>> If we simply add the Mini-OS headers to the gcc search path, then
>> things actually get worse, because they're inconsistent with the
>> system headers. In particular, gmp probes for various header files,
>> finds some Linux-specific ones, and then gets upset when they don't
>> work.
>> Ideally, Mini-OS would compile with -nostdinc and provide all the
>> headers it needs itself. Unfortunately, this requires adding a lot of
>> standard headers with information the C compiler already knows. It
>> seems you can't do this automatically:
>> http://stackoverflow.com/questions/2681304/compile-for-freestanding-environment-with-gcc
>> I tried adding the ones that seemed to be missing. These were needed
>> to compile Mini-OS itself with -nostdinc:
>> inttypes.h
>> limits.h
>> stdarg.h
>> stddef.h
>> stdint.h
>> strings.h
>> However, to compile other programs (e.g. openlibm) requires more. For 
>> example:
>> sys/cdefs.h
>> complex.h
>> (this is as far as I've got)
>> In short, there's a fair bit of work needed to get everything
>> compiling against the correct headers.
> MiniOS uses the gcc search path to find some of these headers;
> https://github.com/mirage/xen/blob/master/stubdom/Makefile#L35
> # Do not use host headers and libs
> GCC_INSTALL = $(shell LANG=C gcc -print-search-dirs | sed -n -e 's/install: 
> \(.*\)/\1/p')
> TARGET_CPPFLAGS += -U __linux__ -U __FreeBSD__ -U __sun__
> TARGET_CPPFLAGS += -nostdinc
> TARGET_CPPFLAGS += -isystem $(MINI_OS)/include/posix
> TARGET_CPPFLAGS += -isystem $(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/include
> TARGET_CPPFLAGS += -isystem $(GCC_INSTALL)include
> Does something like this help, or is the problem the include_next
> of stdint.h that means that it's needed on the search path anyway?

Ah, that saves finding BSD-licensed versions to include! Strange that
they use it for building the stubdoms against Mini-OS, but not for
Mini-OS itself.

There was an include_next problem somewhere, but I can't remember
where. I think it could be avoided with the freestanding option, but
I'm not sure what other effects that has (as I recall, it resulted in
less efficient code, anyway).

>> It's also not completely clear to me how to package 3rd-party
>> libraries such as zarith, which are unlikely to accept patches for our
>> xen_linkopts system (which is essentially a hack around the current
>> lack of cross-compilation support in opam).
>> We previously discussed adding opam depexts to the official package,
>> pointing to our own zarith-xen package for the C stubs. However, this
>> relies on our package providing exactly the correct versions of the C
>> stubs to work with the main package. Not impossible with some version
>> constraints, but it seems messy.
> It's a little messy, but it would work with the version constraints
> (especially given how infrequently zarith is updated).  Best option
> for now?
> -anil

Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

MirageOS-devel mailing list



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