From patchwork Sat Sep 4 12:47:05 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Iain Sandoe X-Patchwork-Id: 63774 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 157B3B7147 for ; Sat, 4 Sep 2010 22:47:32 +1000 (EST) Received: (qmail 25318 invoked by alias); 4 Sep 2010 12:47:30 -0000 Received: (qmail 25304 invoked by uid 22791); 4 Sep 2010 12:47:29 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE, TW_BJ, TW_GC X-Spam-Check-By: sourceware.org Received: from c2beaomr03.btconnect.com (HELO c2beaomr03.btconnect.com) (213.123.26.181) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 04 Sep 2010 12:47:17 +0000 Received: from thor.office (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by c2beaomr03.btconnect.com with ESMTP id MLG36136; Sat, 4 Sep 2010 13:47:06 +0100 (BST) X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=0001.0A0B0302.4C823FCA.00A7, actions=tag Cc: Mike Stump , gcc patches , Ian Lance Taylor , tom.browder@gmail.com Message-Id: <2B0DD900-561C-44FB-B3BC-E629E10EF0D1@sandoe-acoustics.co.uk> From: IainS To: "Joseph S. Myers" , Philip Herron In-Reply-To: Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: Objective C/C++ Compiler Drivers Date: Sat, 4 Sep 2010 13:47:05 +0100 References: <4C6B6392.8080108@gcc.gnu.org> X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Joseph, Phil, On 4 Sep 2010, at 01:34, Philip Herron wrote: > On 4 September 2010 01:29, Joseph S. Myers > wrote: >> On Sat, 4 Sep 2010, Philip Herron wrote: >> >>> Then does it make sense for a compiler driver to be generated from >>> some kind of a config, i agree i've always found the compiler >>> drivers >>> a frustrating thing, since for the most part all will do pretty >>> similar things, most customizations would be add extra linker >>> options >>> i guess. I am not sure if that means we would have a build system to >>> generate it from a bash script and add extra options to the >>> config-lang.in to generate this or something. >> >> I am suggesting something much simpler: incremental refactoring of >> the >> existing code, moving shared utility functions to gcc.c, so that in >> the >> end most drivers can call a shared function and pass a C structure >> to it. >> Not anything requiring generator programs. >> >> For example, you might adapt the Fortran functions such as >> append_arg to >> allocate space dynamically rather than hardcoding limits on the >> size of >> the new array of options based on the old one, move them to gcc.c >> with >> declarations in gcc.h and make all drivers use them. That could be >> one of >> the incremental patches. Subsequent ones might try to identify >> what is >> common about the logic to add language-specific libraries. >> >> There is an idea that we don't really want all these drivers at all >> - we >> want "gcc" to link in the right libraries automatically for whatever >> languages were used for the object files it is asked to link - which >> certainly requires those libraries to be described by suitable >> datastructures gcc.c can use. >> >> -- >> Joseph S. Myers >> joseph@codesourcery.com >> > > Ah ok i see what you mean now, thanks by the way. I'll play around > with that now and see what happens and do it for the objc front-end > first. I am not really sure why the drivers don't append the lang-specific libs to the outfiles array in lang_specific_pre_link ()? I'm also not sure why gcj does it differently and inserts via a hijacked libgcc spec? Assuming that there are Good Reasons for these...... @@ -80,13 +81,28 @@ objc/objc-act.o : objc/objc-act.c \ $(LANGHOOKS_DEF_H) $(HASHTAB_H) $(C_PRAGMA_H) gt-objc-objc-act.h \ $(GIMPLE_H) c-lang.h +objc-spec.o: $(srcdir)/objc/objc-spec.c $(CONFIG_H) $(SYSTEM_H) \ + coretypes.h $(DIAGNOSTIC_H) $(TREE_H) $(FLAGS_H) toplev.h langhooks.h $(TM_H) + $(CC) $(GPY_CFLAGS) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $ (DRIVER_DEFINES) \ + $(INCLUDES) $(LDFLAGS) -c -o $@ $(srcdir)/objc/objc-spec.c + +OBJC_D_OBJS = $(GCC_OBJS) objc-spec.o version.o prefix.o intl.o +g-objc$(exeext): $(OBJC_D_OBJS) $(EXTRA_GCC_OBJS) $(LIBDEPS) + $(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \ + $(OBJC_D_OBJS) $(EXTRA_GCC_OBJS) $(LIBS) + +# Create a version of the objc driver which calls the cross-compiler. +objc-cross$(exeext): g-objc$(exeext) + -rm -f objc-cross$(exeext) + cp g-objc$(exeext) objc-cross$(exeext) + objc.srcextra: # # Build hooks: -objc.all.cross: -objc.start.encap: +objc.all.cross: objc-cross$(exeext) +objc.start.encap: g-objc$(exeext) objc.rest.encap: objc.info: objc.install-info: @@ -96,6 +112,7 @@ objc.install-pdf: objc.html: objc.install-html: objc.man: +objc.install-man: objc.srcinfo: objc.srcman: objc.install-plugin: @@ -109,12 +126,18 @@ lang_checks += check-objc # # Install hooks: # cc1obj is installed elsewhere as part of $(COMPILERS). +# Handled here too with the new objc-spec.c driver. -objc.install-common: +objc.install-common: installdirs + -rm -f $(DESTDIR)$(bindir)/$(OBJC_INSTALL_NAME)$(exeext) + -$(INSTALL_PROGRAM) g-objc$(exeext) $(DESTDIR)$(bindir)/$ (OBJC_INSTALL_NAME)$(exeext) + -chmod a+x $(DESTDIR)$(bindir)/$(OBJC_INSTALL_NAME)$(exeext) -objc.install-man: +objc.install-plugin: objc.uninstall: + -rm -rf $(DESTDIR)/$(bindir)/$(OBJC_INSTALL_NAME)$(exeext) + # # Clean hooks: # A lot of the ancillary files are deleted by the main makefile. @@ -144,3 +167,6 @@ objc.stageprofile: stageprofile-start -mv objc/*$(objext) stageprofile/objc objc.stagefeedback: stagefeedback-start -mv objc/*$(objext) stagefeedback/objc + +config.status: objc/config-lang.in + ==== as for factoring: What do you think of these as common functionality to be collected up? 1/ determining that the action is PCH (and ensuring that no link commands are put into the driver line -- these cause collect2 to be invoked which barfs because there is no linking to do). [g++ fails on this as of now] 2/ the repeated sequence of actions for a 'static-xxxx' flag: NOTE: when encountering a "static-xxxx" flag - please do not remove this (or , specifically, ensure that it is replaced when linking) so that targets that use spec substitution (i.e. those that do not support Bstatic/Bdynamic) for static libs can see it. [g++ fails on this too, at present, fortran has it right] 3/ consider that the input files might be supplied from a file list and that should be considered before quitting with a "no files, not prepared to ... " Phil, your spec file works for me on i686-darwin9 (for NeXT and gnu- runtimes) with the modified Makefile fragment below. cheers, Iain Index: gcc/objc/Make-lang.in =================================================================== --- gcc/objc/Make-lang.in (revision 163837) +++ gcc/objc/Make-lang.in (working copy) @@ -39,13 +39,14 @@ # # Define the names for selecting Objective-C in LANGUAGES. objc: cc1obj$(exeext) +.phony: objc -# Tell GNU make to ignore these if they exist. -.PHONY: objc - -# Use maximal warnings for this front end. +# Use strict warnings for this front end. objc-warn = $(STRICT_WARN) +OBJC_INSTALL_NAME := $(shell echo objc|sed '$(program_transform_name)') +OBJC_TARGET_INSTALL_NAME := $(target_noncanonical)-$(shell echo objc| sed '$(program_transform_name)') + # Language-specific object files for Objective C. OBJC_OBJS = objc/objc-lang.o objc/objc-act.o