RE: [gentoo-alt] FW: x86-winnt

[Markus Duft]

>
> > > To keep things separated, those native windows binaries are installed
> > > in a "child-prefix". First off all a "parent-prefix" is needed, which
> > > is an interix prefix right now (may be cygwin too in the future?). from
> > > there the winnt cross compiler is installed (parity). After that I
> > > manually created some wrappers right now, but I (and haubi) thought of
> > > screwing up the existing gcc-config and binutils-config packages to get
> > > those right (FYI I attached the two wrappers). I then symlinked
> > > /opt/gentoo.system/usr/i586-pc-winnt6.0/bin/{gcc,ld} to
> > > /opt/gentoo.system/usr/bin/i586-pc-winnt6.0-{gcc,g++,ld} (yes, both gcc
> > > and g++ point to the gcc wrapper).
>
> I don't think I understand this completely.  Are you doing "normal"
> cross-compilation, and/or do you use Portage's ability to use a
> different "target" EPREFIX than the configured one?  (e.g. env
> EPREFIX="/my/some-arch/prefix" CHOST="some-arch-blaX" emerge mypackage)

The latter one, but I use CBUILD instead of CHOST, so it's not a "real" cross compilation - see below.

>
> > > Now the child-prefix can be set-up with bootstrap-prefix.sh like this:
> > >
> > > $ CHOST=i586-pc-winnt6.0 EPREFIX=/opt/gentoo.winnt
> > > /opt/gentoo.system/usr/portage/scripts/bootstrap-prefix.sh tree
> > > $ CHOST=i586-pc-winnt6.0 EPREFIX=/opt/gentoo.winnt
> > > /opt/gentoo.system/usr/portage/scripts/bootstrap-prefix.sh setup
> > >
> > > Now one can emerge winnt packages (only parity so far...):
>
> So what is it?  Is the i?86-pc-winntX a full install (having @system
> emerged somehow) or is it only the result of cross-compiled stuff?

There is no @system. This _must_ be provided by an interix parent prefix. It would take more than just ages to get @system for native windows - although that’s the great, far away goal :)

So the winntXX prefixes only contain those packages compiled for native windows. The separate prefix is just so that the interix and winnt binaries/libraries/headers don't interfere. (fex it would be fatal, if the windows linker would find interix libs...)

>
> > > $ CBUILD=i586-pc-winnt6.0 EPREFIX=/opt/gentoo.winnt emerge -v
> parity
>
> Hmm... CBUILD?  Isn't the building machine the interix thing?  Correct
> me if I'm wrong.  I know haubi did some work on cross-compilation with
> Prefix recently, but I haven't managed to catch up with him on that...

No, it's not cross-compiling, since this poses some problems I want to get around. In reality, and if you're really picky, what I want to do _is_ cross compiling, since the compiler is an interix build, and the target is winnt. But since I can execute the windows binaries from the interix environment, I want to get around all those "oh, you're cross-compiling, so let's do some dangerous magic/assumption, since we cannot exec what we produce", which is wrong here.

This is the reason for setting CBUILD, since this changes all 3 host triplets (build, host, target), so in the end it's all winnt, and the build thinks everything is native, which makes porting much easier (this is also the way I did it until now here at our company).

>
> > >
> > > Phew, that's it for now :) Any questions/comments?
>
> Can we "bootstrap" a winnt system, or do you always keep on needing the
> "host" (interix or cygwin in this case).  Is it possible to make say
> like an installer that just installs a stage4 Prefix such that you can
> start, say bash, from cmd.exe?

As I said already, this would be the - far away - goal, but this is quite unrealistic right now, since it would take ages of work - especially on the parity.runtime library, which would need to implement such things as fork(), getpty() and such things that don't exist on windows. Fex getpty() and such block ncurses, which blocks bash. Compiling is not so much of a problem, if there is not too much GNUC specific stuff (which needs to be changed to be either general or MS specific then...), only the implementation of runtime functionality is the current problem.

Another noteworthy things is, that if I would manage to compile bash with parity, it would automagically contain code to handle native windows, interix and cygwin paths correctly. This would be really, really, really cool, since with _one_ single binary, all three systems would be happy :)

Also at the moment the code that is compiled with parity needs to be changed a little if either global variables (in C/C++), or static data members for classes (C++ only) are used, since for shared libraries, the access has to happen through an indirection (GNU does this always through the GOT). The Microsoft compiler tries to generate direct access to variables if possible, and adds the indirection if the symbol is marked as dllimport. The goal of some work that I currently do, is to patch the object code at link time, to change the access from direct to indirect (this requires decoding x86 binary code, finding all instructions accessing data symbols directly (functions are indirect always anyway, so they are no problem), and changing the instruction in question to something that indirectly accesses the data symbol. In most cases this also means that the instruction grows bigger (because dereferencing of a pointer has to be added), and uses additional registers, which need to be pushed/popped). The current state is, that I have a library, that is capable of all manipulations/transformations that I need to do for this, and I have all information I need to find all the instruction that require a change - what I need to do, is to map _all_ instructions that _could_ do such a direct access, to instructions that do the same, but indirect through an additional pointer (which is generated by parity at link-time).

Phew... I really should write all this down in some document... ;)

Any more questions, or did I scare away everybody?

Cheers, Markus

>
>
> --
> Fabian Groffen
> Gentoo on a different level
> --
> gentoo-alt@l.g.o mailing list


-- 
gentoo-alt@l.g.o mailing list