PATCH: Guard uses of fork

PATCH: Guard uses of fork

[Mark Mitchell]

This patch uses the HAVE_WORKING_FORK and HAVE_WORKING_VFORK macros
appropriately to guard calls to these functions.  (These macros are
already being defined by autoconf; we just need to use them.)  I'm
checking HAVE_WORKING_FORK, even in the case of the call to vfork in
cli-cmds.c, because autoconf will "#define vfork fork" if there's no
vfork, but there is fork.  I left the CANT_FORK define in place
because that's defined by defs.h in the case __MSDOS__, and Dan says
that configure isn't run in that case.  I think it could safely be
removed (as surely, on __MSDOS__, nothing will define
HAVE_WORKING_[V]FORK, but I don't have a way of testing that.  I'm
happy to make that change as well, if people would like.

OK to apply?

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

2005-03-09  Mark Mitchell  <mark@codesourcery.com>

	* utils.c (internal_vproblem): Guard call to fork with HAVE_FORK.
	* cli/cli-cmds.c (shell_escape): Guard call to vfork with
	HAVE_WORKING_VFORK and HAVE_WORKING_FORK. 

Index: utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.157
diff -c -5 -p -r1.157 utils.c
*** utils.c	24 Feb 2005 13:51:35 -0000	1.157
--- utils.c	10 Mar 2005 02:08:35 -0000
*************** further debugging may prove unreliable."
*** 787,798 ****
--- 787,800 ----
      }
    else
      {
        if (dump_core_p)
  	{
+ #ifdef HAVE_WORKING_FORK
  	  if (fork () == 0)
  	    abort ();		/* NOTE: GDB has only three calls to abort().  */
+ #endif
  	}
      }
  
    dejavu = 0;
  }
Index: cli/cli-cmds.c
===================================================================
RCS file: /cvs/src/src/gdb/cli/cli-cmds.c,v
retrieving revision 1.57
diff -c -5 -p -r1.57 cli-cmds.c
*** cli/cli-cmds.c	24 Feb 2005 13:51:36 -0000	1.57
--- cli/cli-cmds.c	10 Mar 2005 02:08:35 -0000
*************** echo_command (char *text, int from_tty)
*** 482,492 ****
  }
  
  static void
  shell_escape (char *arg, int from_tty)
  {
! #ifdef CANT_FORK
    /* If ARG is NULL, they want an inferior shell, but `system' just
       reports if the shell is available when passed a NULL arg.  */
    int rc = system (arg ? arg : "");
  
    if (!arg)
--- 482,493 ----
  }
  
  static void
  shell_escape (char *arg, int from_tty)
  {
! #if defined(CANT_FORK) || \
!       (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK))
    /* If ARG is NULL, they want an inferior shell, but `system' just
       reports if the shell is available when passed a NULL arg.  */
    int rc = system (arg ? arg : "");
  
    if (!arg)

Re: PATCH: Guard uses of fork

[Daniel Jacobowitz]

On Wed, Mar 09, 2005 at 08:00:05PM -0800, Mark Mitchell wrote:
> 
> This patch uses the HAVE_WORKING_FORK and HAVE_WORKING_VFORK macros
> appropriately to guard calls to these functions.  (These macros are
> already being defined by autoconf; we just need to use them.)  I'm
> checking HAVE_WORKING_FORK, even in the case of the call to vfork in
> cli-cmds.c, because autoconf will "#define vfork fork" if there's no
> vfork, but there is fork.  I left the CANT_FORK define in place
> because that's defined by defs.h in the case __MSDOS__, and Dan says
> that configure isn't run in that case.  I think it could safely be
> removed (as surely, on __MSDOS__, nothing will define
> HAVE_WORKING_[V]FORK, but I don't have a way of testing that.  I'm
> happy to make that change as well, if people would like.
> 
> OK to apply?

This is OK.  I'm not sure my understanding of the DJGPP bits is
correct, but this patch is safe whether I was right or wrong, which is
why I like it.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Guard uses of fork

[Mark Mitchell]

Daniel Jacobowitz wrote:

> This is OK.  I'm not sure my understanding of the DJGPP bits is
> correct, but this patch is safe whether I was right or wrong, which is
> why I like it.

Applied, thanks!

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: PATCH: Guard uses of fork

[Eli Zaretskii]

> Date: Wed, 16 Mar 2005 10:29:23 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sources.redhat.com
> 
> > I left the CANT_FORK define in place because that's defined by
> > defs.h in the case __MSDOS__, and Dan says that configure isn't
> > run in that case.

Dan was wrong: the DJGPP (a.k.a. MSDOS) build does run the configure
script, albeit slightly edited (see config/djgpp/djconfig.sh for the
gory details).

The reason why defs.h defines CANT_FORK for the __MSDOS__ build is
that the DJGPP library does have `fork', but it's a stub that always
fails, and I don't want to depend on the configure script to get this
right.

Re: PATCH: Guard uses of fork

[Daniel Jacobowitz]

On Wed, Mar 16, 2005 at 09:44:24PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 16 Mar 2005 10:29:23 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> > 
> > > I left the CANT_FORK define in place because that's defined by
> > > defs.h in the case __MSDOS__, and Dan says that configure isn't
> > > run in that case.
> 
> Dan was wrong: the DJGPP (a.k.a. MSDOS) build does run the configure
> script, albeit slightly edited (see config/djgpp/djconfig.sh for the
> gory details).
> 
> The reason why defs.h defines CANT_FORK for the __MSDOS__ build is
> that the DJGPP library does have `fork', but it's a stub that always
> fails, and I don't want to depend on the configure script to get this
> right.

Thanks for checking!  Looks like Mark's patch should be OK for DJGPP
then.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: PATCH: Guard uses of fork

[Eli Zaretskii]

> Date: Wed, 16 Mar 2005 08:37:44 -0800
> From: Mark Mitchell <mark@codesourcery.com>
> CC: gdb-patches@sources.redhat.com
> 
> Daniel Jacobowitz wrote:
> 
> > This is OK.  I'm not sure my understanding of the DJGPP bits is
> > correct, but this patch is safe whether I was right or wrong, which is
> > why I like it.
> 
> Applied, thanks!

In the future, when a patch touches something that is related to the
DJGPP port, I'd appreciate if people would wait with committing the
changes until I had the chance to review and okay it.  Even if the
patch looks obviously correct, like in this case.  That's because the
way the DJGPP port is configured and built is tricky and some of its
subtle aspects are just that--subtle.

(And if I don't respond within a day, ping me: I sometimes miss the
original message due to lack of time to read every line.)

TIA