Free-Standing and Non-OS Dependent

[Sriharsha Vedurmudi]

Hello all, esp. Dave and Mike,

    sorry to bother you again. To begin with, I apologise for my 
incomplete or ambiguous question. I would like to represent my problem 
with better clarity.

Our company (a hardware company) has given a contract to another company 
to port gcc onto its proprietory processor. The porting company issued a 
contract in which it mentioned everything (all porting work) as 'NON-OS 
DEPENDENT FUNCTIONALITY ONLY' (which they call as 'Free-Standing 
Implementation').  (First, Im confused if Non-OS Dependent Functionality 
and Free-Standing are one and the same?). Finally, they have delivered a 
port that consisted of gcc, gdb, gas, binutils, glibc and newlib. But 
the functionlity is very limited, meaning we could not do anything like 
malloc, printf, strcat, sin, cos, etc. They say that all this is NOT 
supported in their Free-Standing implementation (which they have penned 
down as Non OS Dependent port). So, were we cheated? I think so because 
a port of newlib should mean we can use printf (atleast a stub has to be 
there). But I need confirmation on this issue.

    Here is what I understand by the free-standing implementation of gcc:
It is a port of gcc using which you can build a OS kernel. It includes 
only 4 headers namely <float.h>, <stdarg.h>,<limits.h>,<stddef.h> 
(excluding Amd 1 and C99 standards).

But, I did not understand what is included in glibc and newlib that 
constitutes the Non-OS Dependent functionality. Can anyone elaborate on 
it?  

Hope Im clearer this time,

Thank you and kind regards,
Sriharsha.

Mike Stump wrote:

> On Apr 26, 2005, at 4:37 AM, Sriharsha Vedurmudi wrote:
>
>> I want to know what is to be expected
>
>
> This is a bizarre question.  I just bought a new car, and I want to  
> know what to know what I should expect out of it.  A new car.
>
> For newlib, you should expect newlib, for glibc, you should expect  
> glibc, for gcc, you should expect gcc, but this I am sure doesn't  
> help you.
>
> There are far too many features and complexities of these software  
> packages to describe them in an email to you fully.
>
> For example, you can expect:
>
>     int i = 42;
>
> to compile, and produce code that allocates a variable named i, and  
> sets the value to 42.
>
> Further, you can expect that if someone paid your porting company to  
> do a simulator for your arch, that you can load and run hello world  
> in gdb.  I don't know if this was done, so, in part, what is  
> expected, is either known to you because it was in a contract, or  
> sold to you, and should be in the documentation.
>
> There are about a million other things to expect, I'll leave them all  
> out, as the question cannot be answered fully.
>
> You can ask your tools what you can expect, by doing things like:
>
> main() {
>     printf("Hi %d\n", 42);
> }
>
> and seeing if that drags in printf.  Chances are it will, then, you  
> can expect it to work.
>
> You can look at the include directory directly, and you can expect  
> that you can #inlcude any file listed there, again, ask the computer,  
> not us.  You can look at the prototypes in those headers, and you can  
> expect to call any of them.  You can do an nm of all the .o and .a  
> files, and you can expect that any symbol defined, you can use in  
> some way.
>
> Also, gcc is the wrong list, please use gcc-help instead.