Why can't gccgo handle this like gnu objective-c runtime handles this?
Why does it need to be designed such it is in a specific section
instead of registering at runtime? Seems like this a bad design of
registering modules really.
On Oct 24, 2010, at 7:52 PM, Ian Lance Taylor <i...@google.com> wrote:
Dave Korn <dave.korn.cyg...@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