From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31016 invoked by alias); 30 Sep 2009 15:00:47 -0000 Received: (qmail 30979 invoked by uid 22791); 30 Sep 2009 15:00:46 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=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; Wed, 30 Sep 2009 15:00:40 +0000 Received: by pxi29 with SMTP id 29so6910995pxi.14 for ; Wed, 30 Sep 2009 08:00:39 -0700 (PDT) Received: by 10.114.165.18 with SMTP id n18mr10755277wae.154.1254322839218; Wed, 30 Sep 2009 08:00:39 -0700 (PDT) Received: from Paullaptop (124-170-16-182.dyn.iinet.net.au [124.170.16.182]) by mx.google.com with ESMTPS id 21sm4374pzk.15.2009.09.30.08.00.35 (version=SSLv3 cipher=RC4-MD5); Wed, 30 Sep 2009 08:00:36 -0700 (PDT) Message-ID: <4F1842D6879348899E3A1999066969F5@Paullaptop> From: "Paul Edwards" To: References: <200909251516.n8PFGPYn014618@d12av02.megacenter.de.ibm.com> In-Reply-To: <200909251516.n8PFGPYn014618@d12av02.megacenter.de.ibm.com> Subject: i370 port - constructing compile script Date: Wed, 30 Sep 2009 17:24: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-09/txt/msg00640.txt.bz2 What is the best way to go from this: Makefile: C_AND_OBJC_OBJS = attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o \ c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o \ C_OBJS = c-lang.o stub-objc.o $(C_AND_OBJC_OBJS) OBJS-common = \ ^Iinsn-attrtab.o \ ^Iinsn-automata.o \ ^Iinsn-emit.o \ ^Iinsn-extract.o \ to: call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bb-reorder.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bitmap.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp bt-load.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp builtins.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp caller-save.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp calls.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp c-aux-info.c %1 %2 %3 %4 %5 %6 %7 %8 %9 call stdcomp c-common.c %1 %2 %3 %4 %5 %6 %7 %8 %9 and then finally to: //ALIAS EXEC ST2CMP,MEMBER=ALIAS //ALLOC@PO EXEC ST2CMP,MEMBER=ALLOC@PO //ATTRIBS EXEC ST2CMP,MEMBER=ATTRIBS //BB@REORD EXEC ST2CMP,MEMBER=BB@REORD //BITMAP EXEC ST2CMP,MEMBER=BITMAP //BT@LOAD EXEC ST2CMP,MEMBER=BT@LOAD //BUILTINS EXEC ST2CMP,MEMBER=BUILTINS //CALLER@S EXEC ST2CMP,MEMBER=CALLER@S //CALLS EXEC ST2CMP,MEMBER=CALLS //C@AUX@IN EXEC ST2CMP,MEMBER=C@AUX@IN //C@COMMON EXEC ST2CMP,MEMBER=C@COMMON I am happy to construct all of this on a Unix system with the various tools (m4 etc) available. But from the Unix system, I need to be able to generate the above very simple compile script, which is a precursor to creating very simple JCL steps (trust me, you don't want to see what ST2CMP looks like). Note that the JCL has the filenames truncated to 8 characters, listed twice, uppercased, and '-' and '_' converted to '@'. I assume I need a C program to do such a conversion. I'm happy to write that C program. But what's the best way to work with the existing infrastructure when writing and running that C program? One idea I had was to have a target that listed all the variables, and then just had an "echo" as the rule to make the ".o" from ".c", and then I could just go "make" to get all the object files listed out, and then I run a separate C program to convert that into the various scripts. Note that the objective is to basically get a list (in the above format) of all necessary C source in order to be able to compile (to assembler, not .o) C programs. I will be building a single executable, ie combining the C front end and i370 back end into a single executable. I know that it is possible, because I already have it working (on 3.4.6). Now the objective is to do it properly. :-) Also note that I'm not 100% sure what variables to use to get the minimum required source, although I would guess GCC_OBJS, C_OBJS plus the individual files listed in ALL_HOST_OBJS. This would be something that would be good to have an explicit variable for - the minimum C files required in the process of converting C to assembler (even though in normal configurations, those C files reside in different executables). So I would like to define such a variable prior to doing the above. Thanks. Paul. P.S. Here are the (intrusive) changes I have had to make so far to get (maybe 3/4 of) GCC 4.4 to compile on a C90-only platform: Index: gcc/system.h =================================================================== RCS file: /cvsroot/gcc4/gcc/system.h,v retrieving revision 1.1.1.1 diff -r1.1.1.1 system.h 180a181 > #ifdef HAVE_SYS_TYPES_H 181a183 > #endif Index: include/sort.h =================================================================== RCS file: /cvsroot/gcc4/include/sort.h,v retrieving revision 1.1.1.1 diff -r1.1.1.1 sort.h 24a25 > #ifdef HAVE_SYS_TYPES_H 25a27 > #endif Index: libcpp/include/cpplib.h =================================================================== RCS file: /cvsroot/gcc4/libcpp/include/cpplib.h,v retrieving revision 1.1.1.1 diff -r1.1.1.1 cpplib.h 26a27 > #ifdef HAVE_SYS_TYPES_H 27a29,30 > #endif > 542,543c545,546 < ino_t ino; < dev_t dev; --- > /* ino_t ino; */ > /* dev_t dev; */ Index: libiberty/xmemdup.c =================================================================== RCS file: /cvsroot/gcc4/libiberty/xmemdup.c,v retrieving revision 1.1.1.1 diff -r1.1.1.1 xmemdup.c 23a24 > #ifdef HAVE_SYS_TYPES_H 24a26 > #endif Index: libiberty/xstrdup.c =================================================================== RCS file: /cvsroot/gcc4/libiberty/xstrdup.c,v retrieving revision 1.1.1.1 diff -r1.1.1.1 xstrdup.c 18a19 > #ifdef HAVE_SYS_TYPES_H 19a21 > #endif ie very little. Not sure what the proper way to deal with that ino_t and dev_t is, but in the past I've simply created my own typedefs: typedef int ino_t; typedef int dev_t; and included them in config.h But I'll deal with that after I've got a comprehensive list of source files.