From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22459 invoked by alias); 12 Aug 2009 16:35:08 -0000 Received: (qmail 21621 invoked by uid 22791); 12 Aug 2009 16:34:48 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 12 Aug 2009 16:34:41 +0000 Received: by wa-out-1112.google.com with SMTP id m38so17103waf.8 for ; Wed, 12 Aug 2009 09:34:37 -0700 (PDT) Received: by 10.114.16.15 with SMTP id 15mr219446wap.26.1250094877105; Wed, 12 Aug 2009 09:34:37 -0700 (PDT) Received: from Paullaptop (203-206-7-21.dyn.iinet.net.au [203.206.7.21]) by mx.google.com with ESMTPS id j26sm12950112waf.28.2009.08.12.09.34.33 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Aug 2009 09:34:35 -0700 (PDT) Message-ID: <7F6F71C82A5F4C3DBBA620CCD0081FCD@Paullaptop> From: "Paul Edwards" To: "Ulrich Weigand" , "Paolo Bonzini" Cc: References: <200908121348.n7CDmrV1012019@d12av02.megacenter.de.ibm.com> In-Reply-To: <200908121348.n7CDmrV1012019@d12av02.megacenter.de.ibm.com> Subject: Re: i370 port Date: Wed, 12 Aug 2009 17:27: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/msg00197.txt.bz2 Thanks guys for your reply. > As Paolo mentioned, the -dA flag is an option to the *compiler* that > causes it to place additional information into its output stream > (the assembler source code). [from Paolo] > Only DWARF-2 output supports it currently, but if you want to use it say > together with STABS, it is just a matter of modifying dbxout_source_line > and add a single statement like this: > > if (flag_debug_asm) > fprintf (asm_out_file, "\t%s %s:%d\n", ASM_COMMENT_START, > filename, line); Ok, after a few false leads, I found something that produced a pleasing result. Fantastic I should say! With this mod: C:\devel\gcc\gcc>cvs diff debug.c Index: debug.c =================================================================== RCS file: c:\cvsroot/gcc/gcc/debug.c,v retrieving revision 1.1.1.1 diff -r1.1.1.1 debug.c 20a21,31 > #include "output.h" > #include "flags.h" > > void > fff (line, text) > unsigned int line ATTRIBUTE_UNUSED; > const char *text ATTRIBUTE_UNUSED; > { > if (flag_debug_asm) > fprintf(asm_out_file, "fff %d %s\n", line, text); > } 34c45 < debug_nothing_int_charstar, /* source_line */ --- > fff /*debug_nothing_int_charstar*/, /* source_line */ and the -g -dA options I was able to get exactly what I needed: * Function main code fff 32 world.c * basic block 0 L 2,=V(X) L 2,0(2) LTR 2,2 BE L2 fff 34 world.c * basic block 1 MVC 88(4,13),=A(LC0) B L4 L2 EQU * * basic block 2 fff 38 world.c MVC 88(4,13),=A(LC1) L4 EQU * * basic block 3 LA 1,88(,13) L 15,=V(PRINTF) BALR 14,15 fff 41 world.c SLR 15,15 * Function main epilogue But let me guess - I'm not allowed to modify debug.c and have to decide whether MVS is an sdb, xcoff, dbx, dwarf 1/2, or vms? >> > 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. >> >> Ok, actually it doesn't matter if it doesn't work all the time. I'll >> always be compiling with -Os anyway, so it sounds like I'm in >> with a chance of the whole file being read first? >> >> If so, where is my first opportunity, in 3.2.3, to see if there's a >> "main" function in this file? > > Hmm, it seems 3.2.x would *always* operate on a function-by-function > basis. The unit-at-a-time mode was only introduced with 3.4 (I don't > recall if it was already present in 3.3). I don't think there is any > way in 3.2.3 to check whether there is a "main" function in the file > before it is processed ... Ok, I'll wait until 3.4.6 is working before attempting to get the entry point to 0 then. :-) >> > 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. >> >> GCC on MVS *only* outputs assembler. ie you always have to >> use the "-S" option. >> >> By doing so, it turns GCC into a pure text-processing application, >> which will thus work in any C90 environment. > > Huh. So the user will always have to invoke the linker manually, and > pass all the correct options (libraries etc.)? Correct. Very normal MVS. Where would we be without IEWL? > What is the problem with having GCC itself invoke the linker, just like > it does on other platforms? 1. That requires extensions to the C90 standard. The behaviour of system() is undefined, much less even the existence of fork() etc. 2. The attempt to add functionality to system() in MVS has made leaps and bounds, but has not reached the stage of being able to detect if the SYSPRINT DCB is already open so it knows not to reopen it, and close it, stuffing up the caller. 3. MVS compilers don't normally invoke the linker. That's always a separate step. GCCMVS is an MVS compiler also. It would be normal to generate object code though. But the compiler normally generates the object code, rather than invoking the assembler. In any case, the facility to allocate temporary datasets for HLASM and deciding what space parameters should be used etc etc has not yet been determined, and is unwieldy regardless, and the functionality doesn't exist yet anyway, and may be years away still, if it even makes sense. BFN. Paul.