This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH v2 0/10] Tilera (and Linux asm-generic) support for glibc
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
> > <http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02675.html> 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