This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion about merging Go frontend


Dave Korn <dave.korn.cygwin@gmail.com> writes:

> On 24/10/2010 06:40, Ian Lance Taylor wrote:
>
>> There are three new source code directories: gcc/go, libgo, and elfcpp.
>> The last is currently part of the src repository, where it is used by
>> gold.  I propose moving the master copy of elfcpp to gcc, and handling
>> it like libiberty.
>
>   What about non-ELF platforms?  Will go not be buildable for them?

At present, gccgo is most conveniently used on ELF platforms.  The issue
is how to handle importing a package.  All Go code lives in a package.
When you compile a package, gccgo puts export data into the object file,
in the .go_export section.  This is done using the usual get_section
function.  Support for named sections is required at present, but
nothing else.

However, when you import a package, gccgo needs to locate that data.  In
gccgo I used the elfcpp library to read the data out of an ELF file.
Gccgo can also read the data out of a plain text file, so it can work
with a non-ELF format although some other mechanism, such as objcopy,
would be needed to extract the data from the .go_export section into a
text file.

Of course it would be best if gccgo simply learned how to read other
object file formats.  It would not be particularly difficult, but I
don't have any current plans for working on it.

The dependence on elfcpp is not particularly deep.  It's confined to a
single file, import-elf.cc.  On the other hand elfcpp is not very large,
4500 lines.


>   This is the second ELF-specific object reader library getting dragged into
> the compiler build.  Maybe we should give some consideration to just merging
> the whole of src/ and gcc/ and be done with it, so that all the non-ELF
> targets can get BFD support?

It's hard for me to believe that BFD is the correct answer.  It's poorly
designed for the kinds of things the compiler needs to do.  Any program
which links against BFD effectively links in the GNU linker.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]