Developments - ELF and others
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:
>>>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
>>This just ain't gonna happen.
> I guess not. I don't know how much time Stewart spent on adding it to
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.
Network Engineer, Designer Servers Ltd. http://www.dsvr.co.uk
More information about the gcc