On 25/10/2010 23:49, Mark Mitchell wrote:
> On 10/25/2010 7:01 PM, Dave Korn wrote:
>
>> 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.
>>
>> That could be orthogonal to plugging elfcpp into the role currently
>> occupied
>> by libelf in that reader.
>
> I think it's reasonable to argue that GCC should, going forward, be an
> ELF-only toolchain -- with postprocessing tools for generating PE/COFF,
> Symbian DLLs, Mach-O or what have you. But, we haven't made that
> decision. So, I don't think we should get there by half-measures.
I'll probably be on the other side of that argument, when it comes, for a
combination of political and engineering reasons. But, like you say, let's
not get side-tracked.
> Either we should decide that's what we want to do, or we should try to
> keep the compiler independent of the object file format -- as we have up
> until now.
Ian could fairly point out that LTO was accepted into the compiler before it
was format-agnostic. I would counter that, until such a decision as you
contemplate is actually made, it would have been preferable if it was
format-agnostic from the start. However, we are where we are, and don't want
to let the perfect be the enemy of the good.
> I understand Ian's distaste for BFD, but it is the
> format-independent object file reader we have, so it seems a natural
> choice. And libelf, which we already rely on seems more natural than
> elfcpp, if we're willing to go ELF-only -- unless we're going to replace
> the use of libelf in LTO with elfcpp as well.
Well, TBH, I suggested BFD as a devil's-advocate position. It does indeed
work, but it is kind of clunky, and top-heavy for what the compiler's
requirements actually amount to.
From Ian's description, gccgo has the exact same requirements as LTO: be
able to parse an object file, get a list of sections, and get raw binary
access to the data contained within a named section. This is a problem which
we already have solved. (And indeed LTO's solution also has object writing
capabilities that gccgo doesn't need.)
> In any case, I think we should avoid a single compiler build requiring
> multiple object-file reading libraries.
Code re-use FTW! As far as I can see, we're not going to need anything
significantly more complex than what the LTO-FE already needs, until and
unless we get to a point of integrating the (assembler and) linker into the
compiler itself, which is a long way off for now.
That being the case, I think a reasonable plan would be:
- integrate gccgo, with elfcpp
- then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all
the FEs can share it
- then convert it to use elfcpp (with a bit of file I/O added) and stop using
libelf altogether
- then switch gccgo over to using it
... of which I think all but the first step would even be stage3-friendly.
cheers,
DaveK
