Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [patch] Zap more #ifdef HAVE_VFORK
@ 2001-03-26  8:45 Andrew Cagney
  2001-03-26 16:24 ` Kevin Buettner
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2001-03-26  8:45 UTC (permalink / raw)
  To: GDB Patches

Missed this when re-fixing the autoconfed vfork() call.

	Andrew
? diffs
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.1113
diff -p -r1.1113 ChangeLog
*** ChangeLog	2001/03/26 12:25:30	1.1113
--- ChangeLog	2001/03/26 16:40:15
***************
*** 1,3 ****
--- 1,8 ----
+ 2001-03-26  Andrew Cagney  <ac131313@redhat.com>
+ 
+ 	* fork-child.c (clone_and_follow_inferior): Delete #ifdef
+ 	HAVE_VFORK.
+ 
  2001-03-26  Mark Kettenis  <kettenis@gnu.org>
  
  	* config/i386/tm-symmetry.h (PUSH_ARGUMENTS): #undef.
Index: fork-child.c
===================================================================
RCS file: /cvs/src/src/gdb/fork-child.c,v
retrieving revision 1.10
diff -p -r1.10 fork-child.c
*** fork-child.c	2001/03/23 22:48:44	1.10
--- fork-child.c	2001/03/26 16:40:16
*************** clone_and_follow_inferior (int child_pid
*** 421,434 ****
      error ("error getting pipe for handoff semaphore");
  
    /* Clone the debugger. */
- #ifdef HAVE_VFORK
    if (debug_fork)
      debugger_pid = fork ();
    else
      debugger_pid = vfork ();
- #else
-   debugger_pid = fork ();
- #endif
  
    if (debugger_pid < 0)
      perror_with_name ("fork");
--- 421,430 ----
From ac131313@cygnus.com Mon Mar 26 09:41:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Elena Zannoni <ezannoni@cygnus.com>
Cc: GDB Patches <gdb-patches@sourceware.cygnus.com>
Subject: Re: [rfa] *read.c -Wuninitialized fixes
Date: Mon, 26 Mar 2001 09:41:00 -0000
Message-id: <3ABF7F22.33B94C20@cygnus.com>
References: <3A2206A3.EA2ACA96@cygnus.com> <3A220727.C4087391@cygnus.com> <15038.44723.24996.553357@kwikemart.cygnus.com>
X-SW-Source: 2001-03/msg00468.html
Content-length: 296

Elena Zannoni wrote:
> 
> Better late than never.....
> 
> Yes Ok. I committed this given it has been sitting there for sooo long....

Thanks!

Hmm, with these two in I think it is possible to configure GDB with
--enable-gdb-build-warnings=-Wuninitialized,-Werror.  Just need to
check.

	Andrew


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] Zap more #ifdef HAVE_VFORK
  2001-03-26  8:45 [patch] Zap more #ifdef HAVE_VFORK Andrew Cagney
@ 2001-03-26 16:24 ` Kevin Buettner
  2001-04-06 11:47   ` Andrew Cagney
  0 siblings, 1 reply; 4+ messages in thread
From: Kevin Buettner @ 2001-03-26 16:24 UTC (permalink / raw)
  To: Andrew Cagney, GDB Patches

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] Zap more #ifdef HAVE_VFORK
  2001-03-26 16:24 ` Kevin Buettner
@ 2001-04-06 11:47   ` Andrew Cagney
  2001-04-06 12:14     ` Kevin Buettner
  0 siblings, 1 reply; 4+ messages in thread
From: Andrew Cagney @ 2001-04-06 11:47 UTC (permalink / raw)
  To: Kevin Buettner; +Cc: GDB Patches

Kevin Buettner wrote:
> 
> 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

I know it doesn't make sense :-)  It is how autoconf does it though :-/

> 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.

Ok by me.  In general adding comments explaining how bits of code work
are probably obvious fixes.

>     2) Create a gdb_fork() which does the appropriate thing *and*
>        documents the autoconf cleverness in the guts of gdb_fork().

I don't think this one would work very well.  From memory you're not
ment to return from a vfork().

	Andrew


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [patch] Zap more #ifdef HAVE_VFORK
  2001-04-06 11:47   ` Andrew Cagney
@ 2001-04-06 12:14     ` Kevin Buettner
  0 siblings, 0 replies; 4+ messages in thread
From: Kevin Buettner @ 2001-04-06 12:14 UTC (permalink / raw)
  To: Andrew Cagney; +Cc: GDB Patches

On Apr 6,  2:47pm, Andrew Cagney wrote:

> > 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.
> 
> Ok by me.  In general adding comments explaining how bits of code work
> are probably obvious fixes.

I'll see if I can fit this in one of these days...

> >     2) Create a gdb_fork() which does the appropriate thing *and*
> >        documents the autoconf cleverness in the guts of gdb_fork().
> 
> I don't think this one would work very well.  From memory you're not
> ment to return from a vfork().

You're right.  The results are undefined if vfork's caller returns.

Kevin


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-04-06 12:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-03-26  8:45 [patch] Zap more #ifdef HAVE_VFORK Andrew Cagney
2001-03-26 16:24 ` Kevin Buettner
2001-04-06 11:47   ` Andrew Cagney
2001-04-06 12:14     ` Kevin Buettner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox