From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9563 invoked by alias); 10 Aug 2009 20:16:54 -0000 Received: (qmail 9544 invoked by uid 22791); 10 Aug 2009 20:16:52 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f202.google.com (HELO mail-pz0-f202.google.com) (209.85.222.202) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Aug 2009 20:16:43 +0000 Received: by pzk40 with SMTP id 40so3020333pzk.14 for ; Mon, 10 Aug 2009 13:16:41 -0700 (PDT) Received: by 10.115.49.1 with SMTP id b1mr6759667wak.198.1249935401867; Mon, 10 Aug 2009 13:16:41 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id l38sm7913075waf.18.2009.08.10.13.16.39 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Aug 2009 13:16:41 -0700 (PDT) Message-ID: <55E646C333AF44A69A627CE7D64C0ED9@Paullaptop> From: "Paul Edwards" To: "Ulrich Weigand" Cc: "Daniel Jacobowitz" , References: <200908101857.n7AIvMgc001040@d12av02.megacenter.de.ibm.com> In-Reply-To: <200908101857.n7AIvMgc001040@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Tue, 11 Aug 2009 00:34: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-08/txt/msg00174.txt.bz2 > 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 ... Ok, thanks Ulrich. >> 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. Sorry, my question may not have been clear. When I see main(), I generate the normal MAIN code, and I don't care where this goes. However, given that I now know that a main() exists somewhere in this source file, I need to change the ASM_FILE_START output. I expected that the assembler generation wouldn't happen until after the optimization was completed, and thus, by then, I would know whether this was a main. > 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. That is roughly the case, yes. > 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.) Yes, I can do that, but that means I need to have a linker command line! The way the MVS linker works, I can link my main program, (which obviously doesn't have crt0 in it), and, thanks to the "END" statement, I can specify an entry point. This means no complaint from the linker about a default (and wrong) entry point, and no need for any linker statements. It all automatically resolves. It all works really great! Except - I would ideally like to have an entry point of 0, instead of the typical "58" or whatever my static variables happen to be. (my main is normally at the top). >> 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 Thanks again! That didn't seem to make it into 3.4.6. I was able to apply most of his stuff to 3.4.6, and I will see how far that gets me, before trying to find it in 3.2.3. Or maybe I'll skip it, since the problem doesn't occur on a pure EBCDIC system. :-) >> 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 ... Ok, well - I would be content with just the source line number appearing in the output assembler. Is this information available as each assembler line is output? Thanks. Paul.