undocumented vfork behaviour?
I'm working on getting linux/alpha compatability going in
FreeBSD/alpha I stumbled over some odd fork behaviour that I was
hoping somebody could shed some light on.
Specifically, when a linux/alpha process forks, the child's return
value is the parent's pid rather than zero. I tracked this behaviour
down to the child's code path in the alpha's cpu_fork():
/*
* Set up return-value registers as fork() libc stub expects.
*/
p2tf-tf_regs[FRAME_V0] = p1-p_pid;/* parent's pid */
p2tf-tf_regs[FRAME_A3] = 0;/* no error */
p2tf-tf_regs[FRAME_A4] = 1;/* is child */
In the i386 mips libc Ovfork stubs, I see comments which describe
this behaviour:
/*
* pid = vfork();
*
* %edx == 0 in parent process, %edx == 1 in child process.
* %eax == pid of child in parent, %eax == pid of parent in child.
*
*/
Is this comment purely historical? At least the i386 platform no
longer seems to do this:
If I run the following code on FreeBSD/i386, I see:
parent's pid = 6730
I am the child, result = 0
I must be the parent, result = 6731
Whereas FreeBSD/alpha does this:
parent's pid = 17721
I must be the parent, result = 17721
I must be the parent, result = 17722
Code:
#include sys/syscall.h
#include unistd.h
main()
{
int result;
printf("parent's pid = %d\n", getpid());
result = syscall(SYS_vfork);
if(result == 0)
printf("I am the child, result = %d\n", result);
else
printf("I must be the parent, result = %d\n", result);
exit();
}
Before I "fix it" to act like FreeBSD/i386 (I've already tried it seems to
work OK for FreeBSD OSF1 binaries, and fixes my linux/alpha binary's
problems), I'd like to make sure there aren't any hidden ramifications.
Thanks,
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: undocumented vfork behaviour?
On Thu, Aug 26, 1999 at 10:40:29AM -0400, Andrew Gallatin wrote: [...] Specifically, when a linux/alpha process forks, the child's return value is the parent's pid rather than zero. [...] If I run the following code on FreeBSD/i386, I see: parent's pid = 6730 I am the child, result = 0 I must be the parent, result = 6731 Whereas FreeBSD/alpha does this: parent's pid = 17721 I must be the parent, result = 17721 I must be the parent, result = 17722 The Single Unix Specification says about this: RETURN VALUE Upon successful completion, vfork() returns 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, -1 is returned to the parent, no child process is created, and errno is set to indicate the error. Returning the PPID for the child would break many sources, as you already said. Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L+++(--) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: undocumented vfork behaviour?
I'm working on getting linux/alpha compatability going in FreeBSD/alpha I stumbled over some odd fork behaviour that I was hoping somebody could shed some light on. Specifically, when a linux/alpha process forks, the child's return value is the parent's pid rather than zero. I tracked this behaviour down to the child's code path in the alpha's cpu_fork(): This is a bug. For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. Before Julian argue's that vacation is in error, note that it used to work fine until 3.1. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: undocumented vfork behaviour?
On Fri, 27 Aug 1999 02:20:52 + (GMT) Terry Lambert [EMAIL PROTECTED] wrote: This is a bug. ...but it's a bug in fork(), too. Not just vfork(). For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. ...fwiw, NetBSD fixed the vacation(1) bug and another bug in popen(), both of which manifested themselves when NetBSD got a Real Vfork. ...there's actually a fair amount of code that needs to be checked out and fixed when you have a Real Vfork, exit() vs _exit(), etc. -- Jason R. Thorpe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
undocumented vfork behaviour?
I'm working on getting linux/alpha compatability going in
FreeBSD/alpha I stumbled over some odd fork behaviour that I was
hoping somebody could shed some light on.
Specifically, when a linux/alpha process forks, the child's return
value is the parent's pid rather than zero. I tracked this behaviour
down to the child's code path in the alpha's cpu_fork():
/*
* Set up return-value registers as fork() libc stub expects.
*/
p2tf-tf_regs[FRAME_V0] = p1-p_pid;/* parent's pid */
p2tf-tf_regs[FRAME_A3] = 0;/* no error */
p2tf-tf_regs[FRAME_A4] = 1;/* is child */
In the i386 mips libc Ovfork stubs, I see comments which describe
this behaviour:
/*
* pid = vfork();
*
* %edx == 0 in parent process, %edx == 1 in child process.
* %eax == pid of child in parent, %eax == pid of parent in child.
*
*/
Is this comment purely historical? At least the i386 platform no
longer seems to do this:
If I run the following code on FreeBSD/i386, I see:
parent's pid = 6730
I am the child, result = 0
I must be the parent, result = 6731
Whereas FreeBSD/alpha does this:
parent's pid = 17721
I must be the parent, result = 17721
I must be the parent, result = 17722
Code:
#include sys/syscall.h
#include unistd.h
main()
{
int result;
printf(parent's pid = %d\n, getpid());
result = syscall(SYS_vfork);
if(result == 0)
printf(I am the child, result = %d\n, result);
else
printf(I must be the parent, result = %d\n, result);
exit();
}
Before I fix it to act like FreeBSD/i386 (I've already tried it seems to
work OK for FreeBSD OSF1 binaries, and fixes my linux/alpha binary's
problems), I'd like to make sure there aren't any hidden ramifications.
Thanks,
Drew
--
Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin
Duke University Email: galla...@cs.duke.edu
Department of Computer Science Phone: (919) 660-6590
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: undocumented vfork behaviour?
On Thu, Aug 26, 1999 at 10:40:29AM -0400, Andrew Gallatin wrote: [...] Specifically, when a linux/alpha process forks, the child's return value is the parent's pid rather than zero. [...] If I run the following code on FreeBSD/i386, I see: parent's pid = 6730 I am the child, result = 0 I must be the parent, result = 6731 Whereas FreeBSD/alpha does this: parent's pid = 17721 I must be the parent, result = 17721 I must be the parent, result = 17722 The Single Unix Specification says about this: RETURN VALUE Upon successful completion, vfork() returns 0 to the child process and returns the process ID of the child process to the parent process. Otherwise, -1 is returned to the parent, no child process is created, and errno is set to indicate the error. Returning the PPID for the child would break many sources, as you already said. Björn -- -BEGIN GEEK CODE BLOCK- GCS d--(+) s++: a- C+++(-) UBOSI$ P+++(-) L+++(--) !E W- N+ o+ K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+ --END GEEK CODE BLOCK-- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: undocumented vfork behaviour?
I'm working on getting linux/alpha compatability going in FreeBSD/alpha I stumbled over some odd fork behaviour that I was hoping somebody could shed some light on. Specifically, when a linux/alpha process forks, the child's return value is the parent's pid rather than zero. I tracked this behaviour down to the child's code path in the alpha's cpu_fork(): This is a bug. For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. Before Julian argue's that vacation is in error, note that it used to work fine until 3.1. Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: undocumented vfork behaviour?
On Fri, 27 Aug 1999 02:20:52 + (GMT) Terry Lambert tlamb...@primenet.com wrote: This is a bug. ...but it's a bug in fork(), too. Not just vfork(). For other bugs in vfork(), look at the fact that the vacation program does not correctly deal with messages. ...fwiw, NetBSD fixed the vacation(1) bug and another bug in popen(), both of which manifested themselves when NetBSD got a Real Vfork. ...there's actually a fair amount of code that needs to be checked out and fixed when you have a Real Vfork, exit() vs _exit(), etc. -- Jason R. Thorpe thor...@nas.nasa.gov To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
