Where to implement fork()

[Christian Haake]

Am 09.07.2012 um 23:54 schrieb Jeff Johnston <jjohnstn@redhat.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.

Thanks again Jeff. I'll have a look tomorrow. 
Have a nice day...

> 
>> 
>>> 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.
Chris