Developments - ELF and others

Christian Ludlam chris at
Fri Oct 3 07:04:59 PDT 2003

On 3 Oct Peter Naulls wrote:

> In message <3F7D77A2.7010103 at>
>           Nick Burrett <nick at> wrote:
> > Hmm.  Not particularly bad.  Doesn't this involve just porting UnixLib 
> > assembler source to a syntax that 'gas' can read ?
> In the past to do this, I've used preprocessor macros to make it work.
> (use file.S with GCC) But this might upset people compiling with
> Norcroft. Alternatively, adding to 'as':

I'd prefer to have as support ELF, since I personally detest gas's syntax
with a passion. An alternative is to write a script / program which can
convert into gas syntax when making an ELF build.

> > I'm not sure whether I see this as a concern or not.  I've always 
> > considered that the ELF toolset would be a very different beast to the 
> > AOF toolset.  I'd rather see an ELF toolchain that worked and at least 
> > proved the concept rather than trying to fix 'as' to work with ELF.

I think the concept is already proven - we know that ELF works on RISC OS (I
had a fairly sizeable Wimp app working from ELF sometime last year).

> 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.

I'd agree.

> > > 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'.

Not enough, I don't think. It has the -shl option to output a shared library
stub - I managed to work out the format of this file, basically:


It didn't seem to support symbol renaming. Unfortunately, the resulting stubs
files apparantly don't contain any information about which library the stub
applies to, making it somewhat difficult for a loader to load the right


> 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.

Are there any libraries which GCC / UnixLib relies on that can't be
recompiled into ELF? I think you can also put ELF objects into an ALF
library, so that isn't a problem (not that we can't port ar easily enough).

> In the meantime, I will continue to put together an ELF only toolchain,
> and see how it goes.

binutils seems to be portable relatively easily - I have a cross-compiling
GCC running on RISC OS and targeting the AVR, built on OpenBSD. It claimed
that this configuration wasn't supported by libiberty, so I copied that from
the RISC OS GCC distibution, everything else just worked.

Christian Ludlam
chris at

More information about the gcc mailing list