public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug driver/18006] New: Please replace vfork() with fork()
@ 2004-10-15 5:57 d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-15 9:32 ` [Bug driver/18006] " schwab at suse dot de
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: d dot yu dot bolkhovityanov at inp dot nsk dot su @ 2004-10-15 5:57 UTC (permalink / raw)
To: gcc-bugs
When built gcc-4.0 (20041010 snapshot), I discovered that GCC again uses vfork()
instead of regular fork(). This is a "bad thing" due to following reasons:
- vfork() is deprecated -- it was a BSD kludge from old no-MMU-days (a
politically-correct reason :-).
- At least in Linux, vfork()s can't be followed by strace/ltrace, which makes
debugging obscure situations MUCH harder.
Of course, one can say "so -- build your own copy with vfork() disabled" (BTW --
how? There is no "--enable-vfork/--disable-vfork".).
But even having an OPPORTUNITY for vfork() to be used is a danger -- someone
else can supply you a vfork'ed GCC, which is undebuggable. For example, I've
spent many hours trying to find out why some cross-compiler for PPC fails (it
simply ignored the "-B" switch), while being able to strace it could give the
clue in a minute.
Interestingly, gcc-3.4.2, built in exactly the same way (../gcc-3.4.2/configure
--prefix=/tmp/gcc-3.4 --enable-languages=c,c++) does "the right thing" -- it
uses fork().
--
Summary: Please replace vfork() with fork()
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: d dot yu dot bolkhovityanov at inp dot nsk dot su
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug driver/18006] Please replace vfork() with fork()
2004-10-15 5:57 [Bug driver/18006] New: Please replace vfork() with fork() d dot yu dot bolkhovityanov at inp dot nsk dot su
@ 2004-10-15 9:32 ` schwab at suse dot de
2004-10-15 9:46 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: schwab at suse dot de @ 2004-10-15 9:32 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From schwab at suse dot de 2004-10-15 09:32 -------
> - vfork() is deprecated -- it was a BSD kludge from old no-MMU-days (a
> politically-correct reason :-).
Use of vfork is still a win if you are going to call execve anyway because the
address space does not need to be copied.
> - At least in Linux, vfork()s can't be followed by strace/ltrace, which makes
> debugging obscure situations MUCH harder.
This is wrong. At least strace has no problem following vfork.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug driver/18006] Please replace vfork() with fork()
2004-10-15 5:57 [Bug driver/18006] New: Please replace vfork() with fork() d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-15 9:32 ` [Bug driver/18006] " schwab at suse dot de
@ 2004-10-15 9:46 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-15 9:46 ` schwab at suse dot de
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: d dot yu dot bolkhovityanov at inp dot nsk dot su @ 2004-10-15 9:46 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From d dot yu dot bolkhovityanov at inp dot nsk dot su 2004-10-15 09:46 -------
> Use of vfork is still a win if you are going to call execve anyway because the
> address space does not need to be copied.
Yes, it is a tiny win, since vfork() doesn't require copying of page tables, as
opposed to fork(). But address space isn't copied anyway, thanks to
copy-on-write strategy.
> > - At least in Linux, vfork()s can't be followed by strace/ltrace, which makes
> > debugging obscure situations MUCH harder.
>
> This is wrong. At least strace has no problem following vfork.
>From strace(1) (Fedora Core 2):
"Currently (Linux 2.3.25), strace(1) cannot follow vfork() and requires a
kernel patch."
That is true at least under 2.4; 2.6 shows somewhat better behaviour. But there
is a HUGE amount of 2.4 installations, which will remain for long time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug driver/18006] Please replace vfork() with fork()
2004-10-15 5:57 [Bug driver/18006] New: Please replace vfork() with fork() d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-15 9:32 ` [Bug driver/18006] " schwab at suse dot de
2004-10-15 9:46 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
@ 2004-10-15 9:46 ` schwab at suse dot de
2004-10-15 11:55 ` pinskia at gcc dot gnu dot org
2004-10-15 13:02 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
4 siblings, 0 replies; 6+ messages in thread
From: schwab at suse dot de @ 2004-10-15 9:46 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From schwab at suse dot de 2004-10-15 09:46 -------
> This is wrong. At least strace has no problem following vfork.
I take that back. My tests were broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug driver/18006] Please replace vfork() with fork()
2004-10-15 5:57 [Bug driver/18006] New: Please replace vfork() with fork() d dot yu dot bolkhovityanov at inp dot nsk dot su
` (2 preceding siblings ...)
2004-10-15 9:46 ` schwab at suse dot de
@ 2004-10-15 11:55 ` pinskia at gcc dot gnu dot org
2004-10-15 13:02 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-10-15 11:55 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-15 11:55 -------
But who cares that is strace bug which should be fixed because it works on the BSD (and in fact the BSD
got rid of vfork for a while but now they are adding it back because they found it can faster).
So closing as will not fix.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug driver/18006] Please replace vfork() with fork()
2004-10-15 5:57 [Bug driver/18006] New: Please replace vfork() with fork() d dot yu dot bolkhovityanov at inp dot nsk dot su
` (3 preceding siblings ...)
2004-10-15 11:55 ` pinskia at gcc dot gnu dot org
@ 2004-10-15 13:02 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
4 siblings, 0 replies; 6+ messages in thread
From: d dot yu dot bolkhovityanov at inp dot nsk dot su @ 2004-10-15 13:02 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From d dot yu dot bolkhovityanov at inp dot nsk dot su 2004-10-15 13:02 -------
Andrew, this is not "strace bug", but a vfork() bug that it can't be traced --
strace simply CAN'T do anything to fix it.
If some versions of GCC use fork(), and others -- vfork(), so, GCC in fact
supports both styles, right? So, can this be made at least configurable?
And as for performance... Of course, vfork() is slightly faster, but the
performance gain (microseconds?) is neglectable if compared with times spent on
compilation and optimization...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18006
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-15 13:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-10-15 5:57 [Bug driver/18006] New: Please replace vfork() with fork() d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-15 9:32 ` [Bug driver/18006] " schwab at suse dot de
2004-10-15 9:46 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
2004-10-15 9:46 ` schwab at suse dot de
2004-10-15 11:55 ` pinskia at gcc dot gnu dot org
2004-10-15 13:02 ` d dot yu dot bolkhovityanov at inp dot nsk dot su
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).