patches/gdb/6.3/770-debian_vfork-done-spelling.patch
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sun May 20 13:48:26 2007 +0000 (2007-05-20)
changeset 112 ea15433daba0
permissions -rw-r--r--
Ah! I finally have a progress bar that doesn't stall the build!
- pipe size in Linux is only 8*512=4096 bytes
- pipe size is not setable
- when the feeding process spits out data faster than the eating
process can read it, then the feeding process stalls after 4KiB
of data sent to the pipe
- for us, the progress bar would spawn a sub-shell every line,
and the sub-shell would in turn spawn a 'date' command.
Which was sloooww as hell, and would cause some kind of a
starvation: the pipe was full most of the time, and the
feeding process was stalled all this time.

Now, we use internal variables and a little hack based onan offset
to determine the elapsed time. Much faster this way, but still
CPU-intensive.
     1 Index: gdb-6.3/gdb/linux-nat.c
     2 ===================================================================
     3 --- gdb-6.3.orig/gdb/linux-nat.c	2004-11-14 00:36:41.000000000 -0500
     4 +++ gdb-6.3/gdb/linux-nat.c	2004-11-15 11:51:43.954161476 -0500
     5 @@ -69,7 +69,7 @@
     6  #define PTRACE_EVENT_VFORK	2
     7  #define PTRACE_EVENT_CLONE	3
     8  #define PTRACE_EVENT_EXEC	4
     9 -#define PTRACE_EVENT_VFORKDONE	5
    10 +#define PTRACE_EVENT_VFORK_DONE	5
    11  #define PTRACE_EVENT_EXIT	6
    12  
    13  #endif /* PTRACE_EVENT_FORK */
    14 @@ -362,7 +362,7 @@ child_follow_fork (int follow_child)
    15  
    16  	      ptrace (PTRACE_CONT, parent_pid, 0, 0);
    17  	      waitpid (parent_pid, &status, __WALL);
    18 -	      if ((status >> 16) != PTRACE_EVENT_VFORKDONE)
    19 +	      if ((status >> 16) != PTRACE_EVENT_VFORK_DONE)
    20  		warning ("Unexpected waitpid result %06x when waiting for "
    21  			 "vfork-done", status);
    22  	    }
    23 @@ -434,7 +434,7 @@ child_follow_fork (int follow_child)
    24  	 generally not encounter vfork (vfork is defined to fork
    25  	 in libpthread.so).
    26  
    27 -	 The holding part is very easy if we have VFORKDONE events;
    28 +	 The holding part is very easy if we have VFORK_DONE events;
    29  	 but keeping track of both processes is beyond GDB at the
    30  	 moment.  So we don't expose the parent to the rest of GDB.
    31  	 Instead we quietly hold onto it until such time as we can