while, I think I got what you mean. <br>I think we just need to make sure the "OS proper" and BSP code do not use<br>some functions from C library. It is a little hard to tell which could be used and which could not be used, I think.<br>
One needs to know the detail implementation of the function in the library<br><br>Is there a list about which method could be used in BSP code?<br><br>Regards<br>Zhongjie<br><br><div class="gmail_quote">On Mon, Jun 15, 2009 at 9:51 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">Zhongjie wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
When you build gcc, you could tell gcc whether you have a c library, when you tell gcc you do not have<br>
a c library, gcc will define "inhibit_libc", the stdio.h included by libgcc2.c is in the section with "inhibit_libc"<br>
defined, when you build gcc to *-elf- or *-eabi- , such arm-elf-gcc or arm-eabi-gcc, you do not need any<br>
c header files for the target.<br>
</blockquote></div>
While this is true for gcc in general, when you build an rtems toolset,<br>
you always build the C library at the same time. This means gcc does<br>
have access to newlib.<br>
<br>
RTEMS "OS proper" code shouldn't be depending on the C Library<br>
much except for base C99 types and methods like the memory<br>
and string code which doesn't require OS support.<br>
<br>
It doesn't impact the design of the OS. It is just a set of features<br>
that are maintained by someone else and always there. <br>
--joel<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Regards<br>
Zhongjie<div class="im"><br>
-----Original Message-----<br>
*From*: Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <mailto:<a href="mailto:Chris%2520Johns%2520%253cchrisj@rtems.org" target="_blank">Chris%20Johns%20%3cchrisj@rtems.org</a>%3e>><br>
*To*: Zhongjie <<a href="mailto:zhurabbit@gmail.com" target="_blank">zhurabbit@gmail.com</a> <mailto:<a href="mailto:Zhongjie%2520%253czhurabbit@gmail.com" target="_blank">Zhongjie%20%3czhurabbit@gmail.com</a>%3e>><br>
*Cc*: <a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a> <mailto:<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a>><br>
*Subject*: Re: about header files used in score<br>
*Date*: Mon, 15 Jun 2009 09:10:59 +1000<br>
<br>
Zhongjie wrote:<br>
> thanks for reply.<br>
> I am just beginning studying RTEMS, the newlib depends on a limited > number of low level functions.<br>
<br>
Welcome.<br>
<br>
> In fact, we do not need any C library to build gcc as a cross complier, > like arm-elf-gcc, only enable the c<br>
> language. what I concerns is that some part of RTEMS should can be > compiled using those compiler.<br>
<br>
If you look in libgcc2.c you will see an include for stdio.h. I have always needed some libc headers to build gcc.<br>
<br>
> Of course, with newlib support, RTEMS works well, it just a little > confused logically for a beginner like me.<br>
> as my understanding, it is a c library depends on a os, not a os depends > a c library.<br>
> I think we could define those types in rtems, then included by gcc and > newlib, but not use those types directly in<br>
> a c library header files. it will make the architecture more clearly.<br>
<br>
GCC and newlib have all the types defined for a specific target and RTEMS uses them.<br>
<br>
Regards<br>
Chris<br>
<br>
<br>
</div></blockquote><font color="#888888">
<br>
<br>
-- <br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
<br>
<br>
</font></blockquote></div><br>