From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12122 invoked by alias); 2 Oct 2009 22:53:46 -0000 Received: (qmail 12114 invoked by uid 22791); 2 Oct 2009 22:53:45 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-px0-f191.google.com (HELO mail-px0-f191.google.com) (209.85.216.191) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Oct 2009 22:53:37 +0000 Received: by pxi29 with SMTP id 29so1526135pxi.14 for ; Fri, 02 Oct 2009 15:53:35 -0700 (PDT) Received: by 10.114.6.14 with SMTP id 14mr4314903waf.158.1254524015604; Fri, 02 Oct 2009 15:53:35 -0700 (PDT) Received: from Paullaptop (124-170-16-182.dyn.iinet.net.au [124.170.16.182]) by mx.google.com with ESMTPS id 21sm890435pzk.11.2009.10.02.15.53.31 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Oct 2009 15:53:33 -0700 (PDT) Message-ID: <7AE4510479514D0E9B72A9B827275199@Paullaptop> From: "Paul Edwards" To: "Ian Lance Taylor" Cc: "Joseph S. Myers" , "Richard Henderson" , References: <200909251516.n8PFGPYn014618@d12av02.megacenter.de.ibm.com><4F1842D6879348899E3A1999066969F5@Paullaptop><4AC39435.8010902@redhat.com><36D486ECFFC04FBD8318DFDD333FD206@Paullaptop> In-Reply-To: Subject: Re: i370 port - constructing compile script Date: Fri, 02 Oct 2009 22:53:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00044.txt.bz2 Hi Ian, thanks for your reply. >> 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. So this would not be considered a Canadian Cross after all, and with configure I only change the target, not the host? > * Write a cross-assembler and cross-linker. Sure, and that's what I'm trying to avoid. I have a perfectly working assembler and linker on MVS already. It's been working for several decades. > * Copy header files and libraries from the host (MVS). That's fine. And use the --with-root option of configure to get them used? > Now you have a complete cross-toolchain running on a supported host > which can produce executables which run on MVS. It's a can of worms just trying to copy MVS load modules. There's meta-data in 2 different places and it needs to be packaged. > * 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.) I spent several minutes going through the config.h looking at the "detected" functions to find a good example. Maybe I should I have getrlimit or getrusage or fputs_unlocked instead. >> 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. Ok. >> 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. Ok, that's no problem. > They > would copy the files to MVS, run the real assembler and linker, and > copy the output back. I might theoretically be able to do such a thing, but that's not what I'm after. I'm just after 200+ assembler files to be produced so that I can zip them up and take them to a real MVS site or whatever to get compiled. It looks like someone just wrote a C compiler in 370 assembler, which is now all natural MVS (the objective of the exercise). > That would be more than 20 lines, but it seems > doable to me. Actually, that would be 0 lines of intrusive code (ie changing GCC itself). > 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. No, I use intrusive code to convert the pexecute call into a static call to cc1 (effectively - I actually intercept it within gcc itself, see below). And that is why I need a Makefile target that includes all the object code. Because I compile the 450,000 lines of C code into 850,000 lines of assembler code to produce a 3.4 MB gcc load module for MVS. Those figures are from gcc 3.4.6. BFN. Paul. *************** *** 2610,2615 **** --- 2623,2631 ---- static int execute (void) { + #ifdef SINGLE_EXECUTABLE + int ret_code = 0; + #endif int i; int n_commands; /* # of command. */ char *string; *************** *** 2756,2761 **** --- 2772,2792 ---- char *errmsg_fmt, *errmsg_arg; const char *string = commands[i].argv[0]; + #ifdef SINGLE_EXECUTABLE + { + int cnt = 0; + + while (commands[i].argv[cnt] != NULL) + { + cnt++; + } + if (strcmp(string, "cc1") == 0) + { + ret_code = toplev_main(cnt, commands[i].argv); + if (ret_code != 0) break; + } + } + #else /* For some bizarre reason, the second argument of execvp() is char *const *, not const char *const *. */ commands[i].pid = pexecute (string, (char *const *) commands[i].argv,