Re: [MirageOS-devel] TLS on Xen status

[Thomas Leonard <talex5@xxxxxxxxx>]

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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel