Where to implement fork()

[Jeff Johnston]

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.