Article on Unixlib

Nick Burrett nick at sqrt.co.uk
Wed Jan 5 03:41:36 PST 2005


Peter Naulls said:
>
> I've written a drobe.co.uk article outlining the issues faced, past and
> present by Unixlib:
>
> http://www.drobe.co.uk/riscos/artifact1253.html
>
> Most of it's boilterplate to fill in the background, but the last
> sections cover some of the issues that we've been discussing here on the
> list about glibc.

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.

I don't think that Gerph's comment on the article about licensing is
entirely correct, otherwise the math library within glibc would become
under the GPL, which it does not, as it is still under a Sun license.


I'd like to think that we could make more use of the SharedUnixLibrary. 
Some musings I have had this morning, could mean that we could use it to
implement 'shm_open' by creating a dynamic area that is private to the SUL
and using it to manage shared memory requests by the user-land application
i.e.

  program calls shm_open
    shm_open calls SharedUnixLibrary_Shm_Open
       SUL allocates appropriate dynamic area space
    shm_open returns pointer to allocated space
  program uses space

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'd be interested to hear anything you might have to
> say on this, or my older article covering ELF:
>
> http://www.drobe.co.uk/features/artifact1236.html

Good article.

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.

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.

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

Nick.





More information about the gcc mailing list