This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i370 port - constructing compile script


"Paul Edwards" <mutazilah@gmail.com> writes:

> 1. First I need to use my current build machine, Linux,
> to first of all convert the i370.md into insn*.c files, then
> generate an xgcc.  The xgcc would be capable of producing
> i370 code so long as I use the "-S" option.  It doesn't really
> matter how this xgcc was created (ie using non-C90
> stuff like fork available on my build machine).
>
> 2. It is now (at the Alaskan stage) that I need a different sort
> of config.h/auto-host.h that excludes things like fork.  I can
> present my i370 include files here, that only include C90
> functions.  It is at this stage that I need it to invoke xgcc
> (still on the build machine), but it will be with the -S option,
> so there will be no .o files (although I could perhaps fake
> that via a scipt to keep "make" happy) and no executable
> built.  The "fake" script could generate JCL at the same time.
> The C90 library (for MVS) also needs to be cross-compiled
> here.
>
> 3. Then I need to assemble all the assembler on real i370
> (MVS).  It is at this point that a real host (ie on i370 MVS)
> xgcc is built.
>
> 4. Then I can use that xgcc (on MVS) to compile arbitary
> C programs.  Technically I could have had a requirement
> for this i370-mvs host compiler to produce say sparc target
> code.

What most people do is:

* Configure gcc as a cross-compiler.
* Write a cross-assembler and cross-linker.
* Copy header files and libraries from the host (MVS).

Now you have a complete cross-toolchain running on a supported host
which can produce executables which run on MVS.

* Use that cross-toolchain to build a version of gcc which runs on
  MVS.  At this step you port gcc to work on MVS.
* Run that gcc on MVS.

(Note that you mention fork, but as you probably know the gcc code
never actually calls fork.  It calls the pexecute routines in
libiberty.  Those routines have been ported to several different
hosts, including MS-DOS.  If you port them to MVS, then you don't have
to worry about fork.)


> To fit into the standard Canadian Cross 3-step model, I need
> to either collapse steps 2 and 3 into 1 theoretical step, executed
> across 2 platforms (compile on one, assemble on another),

Right, people normally do this by using a cross-assembler and
cross-linker.


> I suspect that it will only take 20 lines or similar of intrusive
> Makefile/shell script changes to shoe-horn my way into the
> existing gcc methodology.  All I need to do is force it to use
> my C90 headers at the right spot, so that it stops thinking
> that I have fork etc, and stop it trying to build an executable.
>
> Can someone tell me where to put those 20 lines?

One way to shoe-horn those lines in would be to make your
cross-assembler and cross-linker actually be shell scripts.  They
would copy the files to MVS, run the real assembler and linker, and
copy the output back.  That would be more than 20 lines, but it seems
doable to me.

But I don't understand the bit about C90 headers.  gcc doesn't need
fork, but it does need a way to execute other programs.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]