Re: Porting newlib.

[Jeff Johnston <jjohnstn at redhat dot com>]

Paul Chavent wrote:
> Good morning.
>
> I have some questions about porting Newlib. It seems that for a new 
> platfrom support we typicaly need :
>  - a linkscript (no deal with newlib, but with binutils/ld)
>  - a start code and syscalls implementation (that must be provided for 
> newlib).
>  - some other thing ?

See http://sources.redhat.com/ml/newlib/2004/msg00230.html

> Moreover, your online doc on libc tells us to implement a minimum set of 
> syscalls. For example _exit close etc...
> In this doc, some function begin with an underscore and other not.
> In the syscall.c and libcfunc.c (in the newlib/libc/sys/arm directory) 
> it is explain :
>   - Functions which begin with an underscore are in the system namespace 
> and go in the syscall.c file.
>   - Functions without leading underscore are in the C namespace and go 
> in the libcfunc.c file.
>
> I don't understand the difference between the system namespace and C 
> namespace and my questions are :
>  Are system namespace and C namespaces equivalent to user space and 
> kernel space in the Linux kernel ?
>  Which minimum syscalls should we provide : with underscore or without ?
>  If we provide some underscore functions, should we provide the sames 
> without underscore ?

Read the top of: newlib/libc/include/reent.h for details of how syscalls should 
be named based on reentrancy.  The C namespace is the user's namespace.  The 
library has documented interface names that the user should not expect to use 
(e.g. the user should not call an external variable sin).  For internal 
functions that are needed for the library, we don't want to steal potential 
names from the user's application that aren't explicitly described in the C 
library standard being followed.  For example, if we arbitrarily add an external 
variable called x to the library, imagine the sample applications that would run 
into problems.  Thus, we prefix the internal routines with at least an 
underscore.  For the minimal syscalls required, you should normally provide 
either underscore versions or reentrant underscore versions.  For example, you 
should either provide _open or _open_r.  Typically, platforms supply _open.  For 
a list of these functions, check out the online manual on the web-page which has 
a chapter regarding which ones are needed.  You can also look at existing 
libgloss implementations.

> Ok, a last thing : in the newlib/configure.host there is
>   [code]
>   arm-*-*)
>     if [ "x${newlib_may_supply_syscalls}" = "xyes" ] ; then
>       sys_dir=arm
>     fi
>     ;;
>   [/code]
> and in newlib/libc/sys/arm/Makefile.am :
>   [code]
>   if MAY_SUPPLY_SYSCALLS
>   extra_objs = syscalls.o
>   else
>   extra_objs =
>   endif
>   lib_a_SOURCES = libcfunc.c trap.S
>   [code]
>
> The facts :
>   If newlib may not supply syscalls, the sys_dir is not set and neither 
> syscalls.c or libcfunc.c are used.
>   If newlib may supply syscalls either syscalls.c and libcfunc.c are used.
> The question :
>   Is there any case where syscalls.c is used and libcfunc is not or the 
> oposite ?

This configure flag was put in to try and alleviate a long-standing problem. 
When the syscalls are embedded in libc, it makes it difficult to replace them 
which is required for different board models and simulators.  The arm syscall 
code was initially put into newlib and I want to one day migrate to where it 
always uses syscalls from a separate library built in libgloss.

When you add a new port, you should always put your syscalls in libgloss, 
thereby avoiding the need to use this configuration option.

> Thank you.
>
> Paul.