Developments - ELF and others

Nick Burrett nick at dsvr.net
Fri Oct 3 07:18:58 PDT 2003


Peter Naulls wrote:

> Well, adding ELF to the backed of 'as' where it saves stuff seems
> reasonably trivial. (I'm not an ELF expert) - and the effort is perhaps
> on par with converting the Unixlib assembler, with the bonus of
> forwards compatibility.

The libelf package may be of some help here:
   http://www.stud.uni-hannover.de/~michael/software/


>>>Equally, drlink doesn't support ELF, and we really want to have
>>>interworking with AOF for lots of reasons, even if that results in
>>>static code.  (I'm not really considering the shared library aspects
>>>right now).
>>
>>This just ain't gonna happen.
> 
> 
> I guess not.  I don't know how much time Stewart spent on adding it to
> 'link'.

I think the biggest problems are going to be the distinction between 
different section types in ELF compared to AOF.  Probably a conversion 
from AOF->ELF is possible, but not the other way.

> It seems that doing so is reasonably straight forward, if we forego my
> obvious concerns about backwards compatibility.  This is really my
> biggest concern, so that existing AOFs don't need to be thrown away,
> and assembler rewritten.  I'd particularly appreciate any ideas on the
> Unixlib stuff above.
> 
> In the meantime, I will continue to put together an ELF only toolchain,
> and see how it goes.

I think this would be the best thing to complete first.  By having a ELF 
toolchain, we will gain enough experience with it to work out the 
various compatibility pitfalls before a AOF/ELF toolset merge is worked on.


-- 
Nick Burrett
Network Engineer, Designer Servers Ltd.   http://www.dsvr.co.uk





More information about the gcc mailing list