This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [uClinux-dev] _vfork libc implementation on ARM
- From: David McCullough <david_mccullough at au dot securecomputing dot com>
- To: uClinux development list <uclinux-dev at uclinux dot org>
- Cc: ARM Linux <linux at arm dot linux dot org dot uk>, newlib at sources dot redhat dot com
- Date: Sat, 29 Apr 2006 21:06:26 +1000
- Subject: Re: [uClinux-dev] _vfork libc implementation on ARM
- References: <7f45d9390604281251x48db24cqc5007c46e3da4db7@mail.gmail.com>
Jivin Shaun Jackman lays it down ...
> 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?
Have a look at uClibc/glibc is the best bet. Looks something like this:
vfork:
swi __NR_vfork
...
Cheers,
Davidm
--
David McCullough, david_mccullough@securecomputing.com, Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com