Article on Unixlib

Peter Naulls peter at chocky.org
Wed Jan 5 04:45:11 PST 2005


In message <3098.81.131.190.25.1104925296.squirrel at 81.131.190.25>
          "Nick Burrett" <nick at sqrt.co.uk> wrote:

> I'm not entirely sure why UnixLib was written, but I know that GCC 2.4.5
> came much later than UnixLib, which I think was written to deal with ports
> of NetHack initially -- since the pwd.h and '/etc' directory were
> originally for this purpose.
>
> It was only when I took over that we realised that UnixLib and GCC really
> needed to be developed together.

Thanks, I'll make some modifications.

> I think there is a limit on the number of available dynamic area slots,
> which makes me think that putting all shared memory segments into one slot
> would be more appropriate.

I don't think there's any meaningful limit on the number; but problems
arise when a program indicates that a DA may expand considerably.  You
can then exhaust physical address space quickly.  I think we discussed
this a few years ago, with Ian Jeffrey getting quite worked up about it.
One consideration here is trying to use, on 26-bit systems, to use low
memory DAs, in case we want to try and put code in shared memory
segments.  This might mean we have to allocate DAs shortly after boot.

> Would we really want to interlink AOF and ELF libraries/code ?  I suppose
> we would, but it isn't really ideal.  I think we might hit some APCS
> violation if we do.
> 
> For PIC generated code (if we manage to get it working), we could opt to
> change the APCS followed to the more recent ATPCS, perhaps taking in
> additional features like the passing of floating-point arguments in
> floating-point registers.  PIC code will never be interlinkable with AOF
> code, so I really do think this is an option.

Yes, in other words, the point of supporting AOF is backwards
compatibility for producing statically linked binaries until such time
that we have a shared library system.  Otherwise we might spend a lot of
time recompiling stuff (even though much of it's automated), and also,
say for using StubsG, where we don't have source.  We'll have to
recompile for shared libraries, but that's another issue.

> I've written a perl script that will convert AOF assembler syntax into ELF
> syntax suitable for the 'gas' assembler.  The only thing it doesn't deal
> with is MACRO constructs, but that's not really an issue.

Yes, I have some very evil sed for this; although it's not as big a deal
because the GCCSDK assembler can generate ELF.  There will need to be
some minor changes in Unixlib to support the differences in handling of
weak symbols.

> Consequently I've built my first ELF executable using GCC 4.0 for RISC OS.

Great.  I'm going to be away for a few weeks, but will still keep an eye
on things. I've now checked in a draft of the updated copyright, and
went cross eyed on a re-read of the LGPL, and have tried to clarify the
use for using Unixlib in non-free programs (although I'm only aware of 2
such in RISC OS).

-- 
Peter Naulls - peter at chocky.org        | http://www.chocky.org/
----------------------------------------------------------------------------
RISC OS C Programming                  | http://www.riscos.info/



More information about the gcc mailing list