This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
_vfork libc implementation on ARM
- From: "Shaun Jackman" <sjackman at gmail dot com>
- To: "ARM Linux" <linux at arm dot linux dot org dot uk>, "uClinux development list" <uClinux-dev at uclinux dot org>
- Cc: newlib at sources dot redhat dot com
- Date: Fri, 28 Apr 2006 13:51:54 -0600
- Subject: _vfork libc implementation on ARM
- Reply-to: "Shaun Jackman" <sjackman at gmail dot com>
Would someone please explain to me how vfork is meant to prevent the
child from smashing the parent's stack? I am writing an ARM Linux
implementation for the newlib libc, and vfork has me mystified.
The system call number is passed in r7 on Thumb. r7 must be preserved.
So, I push r7 onto the stack.
_vfork:
push { r7 }
mov r7, #SYS_vfork
swi
pop { r7 }
b _set_errno /* Tail call. */
_vfork returns for the first time, and the user process calls either
execve or _exit. Either of these function calls is going to clobber
the stack, where I've carefully preserved r7.
My conclusion is that I cannot save r7 on the stack. So, I could
implement vfork as an assembler macro that clobbers r7, but I'd rather
it be a linkable function like all the other system calls. Or, save r7
in some statically allocated piece of memory, but this doesn't sound
very thread-safe. Although, I'd have to think a bit more about how
threads and vfork interact. Or, save r7 in one of the clobberable
registers, such as r1-r3, and depend on the kernel not clobbering that
register.
_vfork:
mov r2, r7
mov r7, #SYS_vfork
swi
mov r7, r2
b _set_errno /* Tail call. */
I'm leaning towards this final idea. How is this usually handled?
Cheers!
Shaun