This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] Zap more #ifdef HAVE_VFORK
- To: Andrew Cagney <ac131313 at cygnus dot com>, GDB Patches <gdb-patches at sourceware dot cygnus dot com>
- Subject: Re: [patch] Zap more #ifdef HAVE_VFORK
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Mon, 26 Mar 2001 17:24:37 -0700
- References: <3ABF722C.EDDEF9BC@cygnus.com>
On Mar 26, 11:45am, Andrew Cagney wrote:
> Missed this when re-fixing the autoconfed vfork() call.
[...]
> /* Clone the debugger. */
> - #ifdef HAVE_VFORK
> if (debug_fork)
> debugger_pid = fork ();
> else
> debugger_pid = vfork ();
> - #else
> - debugger_pid = fork ();
> - #endif
This didn't make any sense to me at first. It did when I went back
and (re)read
http://sources.redhat.com/ml/gdb-patches/2001-01/msg00380.html
What's happening is that AC_FUNC_VFORK is doing #define vfork fork
when the host doesn't have vfork.
Personally, I think the AC_FUNC_VFORK mechanism is being overly clever
and does not contribute to the clarity of the code. We have very few
calls to fork() in gdb and I would much rather see the somewhat more
clunky:
#ifdef HAVE_VFORK
pid = vfork ();
#else
pid = fork ();
#endif
instead of just
pid = vfork ();
with the understanding the vfork might've been magically defined to
be fork.
I'm sure I would feel differently if we had several hundred calls to
fork/vfork in the sources.
If we're going to use the AC_FUNC_VFORK mechanisms, might I suggest
that we do one of the following?
1) Document the fact that the autoconf cleverness *might* actually
have defined vfork to be fork at each use vfork.
2) Create a gdb_fork() which does the appropriate thing *and*
documents the autoconf cleverness in the guts of gdb_fork().
Kevin