This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Discussion about merging Go frontend
- From: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- To: Dave Korn <dave dot korn dot cygwin at gmail dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, Andi Kleen <andi at firstfloor dot org>, Andrew Pinski <pinskia at gmail dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Fri, 29 Oct 2010 09:18:53 -0400
- Subject: Re: Discussion about merging Go frontend
- References: <mcr7hh8qhb5.fsf@google.com> <4CC45302.9000702@gmail.com> <mcrhbgbyoef.fsf@google.com> <4CC59F1E.7040505@codesourcery.com> <mcrbp6ixhny.fsf@google.com> <AANLkTikEy7ER+CkQdWo0XHPoBORvbp8JZ226QFM68PZv@mail.gmail.com> <87pquy3yh5.fsf@basil.nowhere.org> <4CC60C5E.6050605@gmail.com> <mcr1v79bx8q.fsf@google.com> <4CCA8C22.8030308@gmail.com>
On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
> On 29/10/2010 02:31, Ian Lance Taylor wrote:
> > Dave Korn <dave.korn.cygwin@ writes:
> >
> >> What would be even nicer would be if we could share the same code-reader
> >> interface between lto and go (and the lto-plugin), thereby getting object
> >> format independence equally everywhere for no extra cost.
> >
> > How about this?
>
> That looks excellent, thank you!
>
> > This implements an object file reader/writer which does everything
> > required by LTO and gccgo. The ELF code works. I have not tested the
> > Mach-O and COFF code at all beyond compiling it; I hope that somebody
> > else can test those targets and fix them.
>
> I'm right here :) Can't help with Darwin but hopefully Jack/Iain will be
> available.
>
Dave,
Doesn't the go compiler require functional split stack support? Mike Stump
left me with the impression that split stack support would require additional
linker support on darwin.
Jack
> > With this patch, libelf is no longer needed.
> >
> > I've bootstrapped this on x86_64-unknown-linux-gnu, and I've run the LTO
> > testsuite.
> >
> > This patch puts the code in libiberty, but it could equally well go in
> > gcc. Anybody want to make an argument one way or another?
>
> Libiberty is better for sharing with lto-plugin, I think. I sent a patch
> that commoned out some of the COFF-reader code into gcc/, but I only put it
> there because it was a single header file with no associated object file. Now
> there's actual code to be linked in, I think libiberty is a better choice than
> lto-plugin trying to share .o files from the ../gcc/ objdir.
>
> > Does the general interface look OK?
> >
> > This patch requires approval from the LTO maintainers.
>
> Also, I have a patch outstanding to COFF-ize the lto-plugin(*), so if we can
> get an early "OK in principle" I'll get cracking on respinning it to use this
> new interface.
>
> cheers,
> DaveK
> --
> (*) - http://gcc.gnu.org/ml/gcc-patches/2010-10/msg02176.html