Re: Where to implement fork()

[Jeff Johnston <jjohnstn at redhat dot com>]

On 07/09/2012 05:23 PM, Christian Haake wrote:
> On 09.07.2012 21:53, Joel Sherrill wrote:
> > On 07/09/2012 02:23 PM, Christian Haake wrote:
> > > Hi,
> > > while implementing newlib stubs I'm wondering where I should implement
> > > fork().
> > > I successfully implemented _sbrk in
> > > <pathtonewlib>/newlib/libc/sys/arm/syscalls.c but there is no function
> > > stub called _fork(void)
> > > Or can I simply add this function stub into this file?!?
> > > Can anybody give me a hint?
> > I suspect you are adding bare board specific code. This would
> > go in libgloss where there are already a number of stubs
> > for fork() and other methods.
> Yes, it is board specific. I run a
> ./configure target=arm-elf
> in the projects root for targeting arm architecture. Furthermore I
> implemented the syscalls.c in the folder mentioned earlier but did not
> yet consider to do my stuff in the libgloss folder. So thanks for that
> hint.
> But anyhow, in <pathtonewlib>/libgloss/arm/syscalls.c there is no
> function stub for fork() as well.
> A grep for fork in the same folder shows no function stub.
> Do I have to add this stub to syscalls.c ?!? Other kinds of architecture
> do have a fork.c inside.

The syscall function stubs are found in libc/syscalls.

Platforms ask for syscall stubs (which call the underlying syscalls) by 
filling in the syscall_dir parameter in configure.host.  This is already 
specified for arm configurations.

The file libc/syscalls/sysfork.c supplies a stub for fork() which calls 
_fork_r.  The libc/reent folder provides a version of _fork_r that calls 
_fork for platforms that do not directly supply reentrant versions of 
the syscalls.

See the file libc/include/reent.h for a description of the various 
reentrancy set-ups a platform may choose.

> > IMO there are some unfortunately named directories in libc/sys which
> > appear to be generic CPU support but they are really for specific
> > "systems." The sys/arm directory is questionably named because
> > it is really support for the ARM Angel/RDI monitor.  Mostly a
> > confusing historical artifact at this point.
> Thanks, I'll think of it in my future work.

The sys/arm directory is a historical nuisance.  Please update 
libgloss/arm and configure with --disable-newlib-supplied-syscalls

-- Jeff J.