GSOC:disable newlibc reentrancy

[xu ray]

libc_global_reent structure will take 1kb SRAM. This relic is too big for a
system with only a few k sram. Though the pointer to libc_reent is used in
thread dispatch, it is not a must for thread dispatch.


2008/5/8 阎淼 <yanmiaobest at gmail.com>:

> Hi,
>
> I am trying to disable newlibc.c reentrant support. And Our goal is to
> defer as many things as possible to link time. To that end, newlibc.c
> should be splitted. bsp_libc_init(in bsppost.c) calls libc_init, which
> is defined in newlibc.c(in libcsupport directory). There are also some
> libc reentrant hooks defined in newlibc.c plus the libc_global_reent
> variable. So I create a new file newlibc_init.c in
> cpukit/libcsupport/src(of course need to modify the Makefile), which
> has only one function(libc_init, copied from newlibc.c), and a
> variable definition(libc_global_reent copied from newlibc.c), and I
> also move the definition of RTEMS_NEWLIB_EXTENSION  to confdefs.h,
> wrapped by CONFIGURE_DISABLE_NEWLIB_REENTRANCY macro. If you do not
> want newlibc reentrancy support, you define macro
> CONFIGURE_DISABLE_NWELIB_REENTRANCY in your application configuration
> file as before, and libc reentrant hooks will no be linked; If you
> need newlibc reentrancy code, you do nothing.  Is that OK?
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>



-- 
Thanks & Best Regards!

Ray, Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080508/cbd86a0d/attachment-0001.html>