gcc-3.2.3, windows98, cygwin, no luck

[Ed Sutter]

Ok, I suppose I'm "displaying my stupidity", but I'm still
confused.  Please note that I'm not complaining about this,
I just want to make sure I understand it...

> All GCCs are built on top of a target libc and are tied to
> this libc.  This applies to both "Generic gccs w/o OS" as well
> as to "OS-specific GCCs targeting full-fledged, complex OSes"

Not quite sure I understand, so bear with me, and let me 
know if something below is wrong...

There are really two pieces to this:

 1. The cross compilation tools (gcc, etc..).
 2. The libraries built to be used by the target system
    at link time (newlib), which by the way, are built by
    the cross compilation tools.

The cross compilation tools are obviously cpu-specific so that they
generate code that is based on a particular CPU.  But what is it that
the compiler has to do that is RTOS-specific?  And whatever it does,
why can't it be handled in some way that allows the cross compiler
to stay reasonably generic?  I've built pSOS, Nucleus, CMX, UC/OS-II
(etc...) all with the same cross compiler.

The libraries are also cpu-specific so that they can supply the
cross compiler with things like low-level math routines, a common
crt0, etc..  I "kinda" understand that the libraries are RTOS-specific  
because then, for example, "exit" will do something specific for
the RTOS; but even in that case, the RTOS should simply provide the
exit() function so that it is not pulled in by a libarary.  This way
even the library can remain generic because it's not really doing much.
For example... a library supplies printf().  I don't need a different
printf for each target, I just supply the  low-level serial port
interface.  Similarly, in the case of "exit", doesn't it make more
sense to simply supply the RTOS-specific code with the RTOS, instead of
building it into the library?  

> I.e. if somebody is shipping a "generic gcc", they actually ship a "GCC
> built on top of some target libc". Generally, this can be any arbitrary
> libc, anyway this ties this gcc to that particular libc.

I realize that gcc is somewhat tied to the libraries it comes with
for the very basic startup of the system (crt0), low-level math and
things like that, but beyond that I question why further linkage
between the (cross-compiler & libraries) is needed. 

> 2. "OS-specific" GCCs can apply OS-specific optimizations and
> customizations to gcc, which "generic GCCs" have no chance to know
> about.

At the compiler-level, what is an example of an OS-specific optimization?

Sorry for the verbosity!
Ed