In message <Pine.WNT.4.43.0203212020240.1028-100000@todd>Todd Vierling writes
>On Thu, 21 Mar 2002, Jonathan Stone wrote:

>
>Even so, we should be able to make such a tool based on bfd, that could take
>the place of both elf2aout and elf2ecoff.  

Todd,

I think, from your previous message, you're assuming that there's some
well-defined ELF standard, and that's all we have to implement.  The
reality is that elf2ecoff, at least, has to produce ECOFF files which
also meet the stricter constraints of certain PROM loaders.

I dunno the history; maybe ELF wasn't so cleanly defined when those
PROMs wer written. Maybe they just rely on the output, section
ordering, and various levels of alignment and padding, which the Third
Eye tools just happened to generate.

I can try and dig out the messages from last century when I tried
this, and discussed the issues with Ian Lance Taylor. The end-result
was that a BFD-based tool really didn't fit the internal architecture
of the (then-current) BFD read/write design, and that Ian explicilty
wasn't interested in reworking them (or buying back changes) which
made them so.

Sorry to sound like a stuck record here, but we *did* look, we *did*
try to go with BFD tools, and ain't that easy; and finally the (then)
BFD maintainer told us (very politely) to take our EOL'ed PROM constraints,
and go play with them ourselves.


>This was proposed before, and it's something we should look at.

Oh, By all means please look again.  What I recall, though, is someone
an assertion that it could and should be done, without actually doing
the looking :).  Not the same thing at all.


>Anyway, do note that I said that it gives me pause -- but I didn't say
>"don't do it".  Manuel, fortunately, isolated the exec_ecoff.h stuff to the
>cross-tool's own ssubdir.  8-)

We agree that's a good thing :).