UnixLib miscellanea

John Tytgat John.Tytgat at aaug.net
Sun Jan 11 15:35:04 PST 2004

In message <20040111212011.GA10433 at chiark.greenend.org.uk>
          Theo Markettos <theo at markettos.org.uk> wrote:

> Some things I think we ought to think about before releasing GCC 3.3:
> Unix$Path (and Unix$anything I think) are registered to Justin Fletcher for
> use in Telnetd.  Telnetd breaks if you start moving its paths underneath it.
> I know this is a really bad time to suggest this, but can we move to
> UnixLib$Path instead (which I hope someone has registered for GCC?)?  OSLib
> have done something similar in moving from OS$Path to OSLib$Path.

Not sure if someone bothered to request the registration of UnixLib related
names or other things.  As far as I can see, the following should at least
be registered :

  - System variables:
  - Application name:
    - UnixLib
      [ This would mean UnixLib$* system variables are registered too. ]
    - CLib
      [ This would mean CLib$* system variables are registered too. ]
    - GCC
      [ This would mean GCC$* system variables are registered too. ]
Do the following need to be requested as well ?

  - Module name:
  - Error block for SharedUnixLibrary: currently 0x81A400 is used, so I
    assume this has been requested.  Correct ?
  - SWI block for SharedUnixLibrary: currently 0x55C80 is used, so I assume  
    this has been requested before.  Correct ?

If you look into !GCC.!Run you will find a lot of other system variables :
  - GCCbin*
  - GCCpkg*
  - GCCsys*
  - GCClcl*
    => Should we register all GCC* system variables (on top of of GCC$*,
       see above) ?
  - GNATada
  - GNATInc
  - GNATlib
    => Should we register all GNAT* ?
  - *$heap  like gcc$heap, gnatbind$head, ...
    Shouldn't we better change this into "UnixEnv$heap" /
    "UnixEnv$<program name>$heap" ? I.e. make it a "feature" ?

Any other things missed ?

I'm willing to do this on behalf of "GCCSDK developers" if something needs
to be done here.  And yes, I think we need to switch from "Unix$Path" (Unix:)
to "UnixLib$Path" (UnixLib:) based on above mentioned information.  :-/

> On an unrelated note, SOMAXCONN was I think defined in UnixLib a while back
> but has now disappeared (from the recent snapshot).  Can we add it (patch
> below)?  The value of 128 I get is from TCPIPLibs (given that UnixLib just
> calls the SWI).  The previous version had 5 which was a former limit of
> Internet 5, now removed.

I'll commit it.

> Also the second patch tweaks source/clib/netinet/tcp.h since Norcroft
> doesn't like making bitfields from anything but ints.  I hope this won't
> cause problems for gcc (would it cause side effects with structure
> alignment?).

I'm not sure if this patch solves all the issues.  E.g. the struct tcphdr,
gcc gives as sizeof() = 20 en offsetof(struct tcphdr, window) = 14.
While Norcroft (at least v5.54) gives 24 and 16 respectively.  I think
you have to change the next struct entry "window" too, e.g. "u_int16_t
window;" -> "u_int32_t window:16;" so that all consecutive bitfields
are merged together into one 32 bit word (otherwise the "window" entry is
aligned to the next 32bit offset).  You agree ?

> Also also, are we going to produce separate UnixLib builds with COMPAT_INET4
> on and off?  Currently #defining it causes bits/sockaddr.h to do the right
> thing but the assembly code in source/clib/unixlib/asm_dec.s has a compile time
> switch - this will cause a mismatch I think.

True.  As there are several feature switches, it is not practible to
generate a release for each unique combination of those switches.  I think
the understanding is that there will be one release for the given set of
switches which is now currently checked in CVS.  If someone want to have
a different setup, he needs to build a new UnixLib himself.  Which, I think,
is not too much of a problem.

My feeling is that when we have a shared UnixLib only setup, several of
those features will be removed.

> Something has gone wrong with the checkout that created the snapshot;
> source/stdlib/rand48.h seems to be missing from the RISC OSified
> copy, as does source/resolv/*.h (has a script missed source/*/*.h
> files?)  Similarly module/* seems to be missing.

Something for Nick ?

> There's probably more to come...

Thanks.  Your feedback is appreciated ! ;-)

John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven

More information about the gcc mailing list