From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10922 invoked by alias); 10 Aug 2009 18:57:39 -0000 Received: (qmail 10913 invoked by uid 22791); 10 Aug 2009 18:57:39 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_05,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate1.de.ibm.com (HELO mtagate1.de.ibm.com) (195.212.17.161) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Aug 2009 18:57:33 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.1/8.13.1) with ESMTP id n7AIvUOA009523 for ; Mon, 10 Aug 2009 18:57:30 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n7AIvO2r2236534 for ; Mon, 10 Aug 2009 20:57:30 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n7AIvNtO001051 for ; Mon, 10 Aug 2009 20:57:24 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id n7AIvMgc001040; Mon, 10 Aug 2009 20:57:22 +0200 Message-Id: <200908101857.n7AIvMgc001040@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Mon, 10 Aug 2009 20:57:22 +0200 Subject: Re: i370 port To: mutazilah@gmail.com (Paul Edwards) Date: Mon, 10 Aug 2009 21:25:00 -0000 From: "Ulrich Weigand" Cc: drow@false.org (Daniel Jacobowitz), gcc@gcc.gnu.org In-Reply-To: from "Paul Edwards" at Aug 08, 2009 09:00:09 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-08/txt/msg00173.txt.bz2 Paul Edwards wrote: > GCC 4 complained (on my Linux system) that I didn't have > various things (gimp etc) installed, which means I would need > that other software to be ported too, which is not a project > I want to work on at the moment. However, at least it means > that i have successfully merged all the GCCMVS changes > to 3.2.3 in with the (last available) 3.4.6 development, which > was a precursor to any GCC 4 port anyway. I'll see over time > how GCC 3.4.6 pans out. This probably is not gimp (the graphics editor) but gmp (the multi-precision integer operation library) and mpfr (same for floating-point). To build any recent GCC you'll indeed need these two libraries. Fortunately, they're already available on s390(x) on Linux, and shouldn't really contain anything that is OS-specific, so porting those to MVS should hopefully be straightforward ... > Until then, back at GCC 3.2.3, I have a "need" to make the entry > point 0 in my MVS modules. > Currently I generate this: [snip] > for a main program. In order to get the entry point to 0, I need to move > that > @@MAIN function to the top of the file. I don't think there is a reliable way to change the sequence of functions / objects in the output file. However, it seems to me it shouldn't really be necessary to treat "main" special. Usually, the "entry point" isn't really "main", but rather some function in crt0.o, which then in turn *calls* main after all startup processing has been done. As crt0.o can be (and usually is) completely written in assembler, you can arrange for everything to be in the sequence that is required. (On the linker command line, crt0.o would be placed first, so if the entry point is the first thing in crt0.o it will then also be the first thing in the executable.) > And I have another question - where is the code for __asm__? > > Currently that is generating garbage for me: > > unsigned int bytes = 258; > > __asm__("? :"); > > int main(void) > > BYTES EQU * > DC F'258' > o@z > * Program text area > > when done in cross-compiler mode, and need to find out where > the literal is being translated (or more likely - failing to be > translated in the first instance). Any idea where that is? Hmm, this seems to be the bug fixed by Eric Christopher in 2004: http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html > And final thing - the interest in the __asm__ comes from the hope > that in the generated 370 assembler, it would be possible to have > the C code interspersed to whatever extent possible. The plan was > to basically somehow get every line of C code, e.g. "int main(void)" > above, and automatically generate an: > __asm__("int main void)"); As you note, this doesn't seem workable as the result wouldn't be syntactically valid ... > which gives a syntax error. Any idea how to get the mixed > C/assembler when I'm running with the "-S" option and don't > have the luxury of calling the normal "as" which would > normally handle that? There doesn't seem to be an easy way to do this from the compiler. At the time compiler output is generated, the original source code text isn't even kept any more; you'd have to go back and re-read the original source files using the line-number debug data, just as the assembler would ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com