Developments - ELF and others

Peter Naulls peter at chocky.org
Fri Oct 3 06:40:28 PDT 2003


In message <3F7D77A2.7010103 at dsvr.net>
          Nick Burrett <nick at dsvr.net> wrote:

> > I've also got a port of "ld", which seems to work, but getting anything
> > useful out of it involves having an ELF C library.
> 
> 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':

> > There are various issues here of course - gas doesn't support the RISC
> > OS assembler format.  Adding ELF output to 'as' remains a possibility.
> 
> 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.

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

>
> > GCC's backend supports outputting GNU format assembler (notionally
> > "riscos-elf"), which I'm going to try compiling, and see how that goes.
> > Code from ARM Linux/NetBSD isn't entirely suitable, lacking chunked
> > stacks, and on non-Debian will have half-word loads.  Although it's not
> > like Unixlib didn't have a non-chunked stack for a long time :-) 
> 
> The stuff in 2.95.4 should work.  The 3.3 stuff probably won't.  I've 
> made a number of changes to riscos-aof.h which haven't been committed 
> yet which would need to be ported across.

I've made a number of changes to bring it up to speed, but nothing
seems amiss.  If this eventually moves to 3.3, then common things
between the two files ought to be put in a single file.

> > The upshot is that I may be able to shortly put together a full RISC OS
> > ELF toolchain, albeit with several limitations.
> 
> This should be a fairly easy task.

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.


-- 
Peter Naulls - peter at chocky.org        | http://www.chocky.org/
----------------------------------------------------------------------------
Drobe - http://www.drobe.co.uk/        | The Premier RISC OS News Site




More information about the gcc mailing list