This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Free-Standing and Non-OS Dependent
- From: Sriharsha Vedurmudi <sriharsha dot v at redpinesignals dot com>
- To: gcc at gcc dot gnu dot org
- Cc: gcc-help at gcc dot gnu dot org
- Date: Wed, 27 Apr 2005 12:50:52 +0530
- Subject: Free-Standing and Non-OS Dependent
- References: <426E27E3.2050307@redpinesignals.com> <77A9D818-5AE9-47FC-A34D-B62E6F263B53@apple.com>
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.