From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28932 invoked by alias); 11 Aug 2009 13:49:15 -0000 Received: (qmail 28924 invoked by uid 22791); 11 Aug 2009 13:49:14 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mtagate4.de.ibm.com (HELO mtagate4.de.ibm.com) (195.212.29.153) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Aug 2009 13:49:07 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n7BDmqfm169374 for ; Tue, 11 Aug 2009 13:48:52 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 n7BDmpDr2707658 for ; Tue, 11 Aug 2009 15:48:52 +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 n7BDmpHp002840 for ; Tue, 11 Aug 2009 15:48:51 +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 n7BDmooM002811; Tue, 11 Aug 2009 15:48:50 +0200 Message-Id: <200908111348.n7BDmooM002811@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 11 Aug 2009 15:48:50 +0200 Subject: Re: i370 port To: mutazilah@gmail.com (Paul Edwards) Date: Tue, 11 Aug 2009 15:21:00 -0000 From: "Ulrich Weigand" Cc: gcc@gcc.gnu.org In-Reply-To: <55E646C333AF44A69A627CE7D64C0ED9@Paullaptop> from "Paul Edwards" at Aug 11, 2009 06:16:35 AM 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/msg00181.txt.bz2 Paul Edwards wrote: > 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. That depends a bit on the compiler version and optimization level, but (in particular in the 3.x time frame) GCC may output assembler code on a function-by-function basis, without necessarily reading in the whole source file first. As I said, it seems the best way would be to not have care at all whether or not any particular source file contains a main routine, but instead do all entry-point processing in the crt0 startup file. > > 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. I don't know exactly how your port handles this on MVS, but usually GCC itself will invoke the linker, and will itself prepare an appropriate command linker for the linker. As part of this command line, things like crt files will be specified. You should set the STARTFILE_SPEC macro in your back-end to do 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? In current GCC, every insn contains "location" information pointing back to source code line (and column) numbers. However, in GCC 3.x I think this wasn't yet present, but you had to rely on line number notes interspersed with the insn stream. In any case, if you build with -g and use in addition the "debug assembler output" flag -dA the assembler output should contain human-readable comments containing line number information. Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com