From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8048 invoked by alias); 15 Nov 2011 18:05:56 -0000 Received: (qmail 8036 invoked by uid 22791); 15 Nov 2011 18:05:54 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 18:05:16 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RQNNj-0006Qd-Cu from joseph_myers@mentor.com ; Tue, 15 Nov 2011 10:05:15 -0800 Received: from digraph.polyomino.org.uk ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Nov 2011 18:05:13 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.74) (envelope-from ) id 1RQNNg-0002kK-Ke; Tue, 15 Nov 2011 18:05:12 +0000 Date: Tue, 15 Nov 2011 18:05:00 -0000 From: "Joseph S. Myers" To: Arnd Bergmann cc: Ulrich Weigand , libc-ports@sourceware.org, Richard Earnshaw , Catalin Marinas Subject: Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc In-Reply-To: <201111151746.12872.arnd@arndb.de> Message-ID: References: <201111100054.pAA0sf6u025585@farm-0002.internal.tilera.com> <6684568.qf2fzy7upl@wuerfel> <201111151746.12872.arnd@arndb.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00056.txt.bz2 On Tue, 15 Nov 2011, Arnd Bergmann wrote: > > (It would be generically desirable to be able to have a single GCC, > > binutils etc. build supporting multiple targets with a --target= or > > similar option to select between them, whether or not those targets share > > a back end in their implementations. But as I discussed at > > that would be a > > lot of work, whereas wrappers round two separate compiler builds are very > > simple - so genuinely multi-target compilers become more relevant if you > > want a single source file to contain functions for different architectures > > - which adds its own complications, although GDB does support different > > call frames being on different architectures.) > > I've discussed this before with Uli Weigand, and I think it would be > very useful to have a multi-target toolchain support, but if I understand > your proposal correctly, you are thinking of a more fundamental version > that actually has a single cc1 binary with support for multiple targets. Yes, I am. The strongest use case being Joern's of heterogenous multicore systems where some functions may run on some cores and some on others - much like the unified Cell debugger which drove multi-target work in GDB. Other than that, the changes are largely valuable cleanups - they result in a cleaner internal architecture, reduce rebuilds when you change things if tm.h is no longer included everywhere [*], make the internals easier to understand and maintain - but it's a lot of work for a cleaner internal architecture. (The parts relating to separating libgcc configuration from host-side configuration have however seen a lot of work from Rainer Orth for 4.7; hopefully that may be finished for 4.8.) [*] At least given a resurrection of automatic dependency generation so you aren't relying on people to remove tm.h dependencies by hand. > I was hoping that we could fix the -b command line option and add proper > support in the build system to build multiple separate sets of target > binaries with a shared driver, but I now saw that the option has been > removed as of gcc-4.6, presumably for good reasons. It has been the case for a very long time that there were many aspects of the driver's behavior that were not controlled purely by specs. So first the compiler was changed, back in 3.3, to exec a different driver if called with -b or -V rather than relying on reading different specs files. Then in 4.6 the options were completely removed (following PR 42485 - there was no interest in fixing these options when they broke). I don't think the version requiring such options to come first and implementing them via execing a different driver would be hard to reimplement - but wrappers aren't hard to implement either. And when your host operating system is GNU/Linux, execing different processes is very fast so the overhead of wrappers shouldn't matter much there. -- Joseph S. Myers joseph@codesourcery.com