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:
[ This would mean UnixLib$* system variables are registered too. ]
[ This would mean CLib$* system variables are registered too. ]
[ 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 :
=> Should we register all GCC* system variables (on top of of GCC$*,
see above) ?
=> 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
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