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