Developments - ELF and others
chris at recoil.org
Fri Oct 3 07:04:59 PDT 2003
On 3 Oct Peter Naulls wrote:
> In message <3F7D77A2.7010103 at dsvr.net>
> Nick Burrett <nick at dsvr.net> 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.
> > > 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
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.
chris at recoil.org
More information about the gcc