From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8817 invoked by alias); 22 Aug 2003 21:20:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8808 invoked from network); 22 Aug 2003 21:20:07 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Aug 2003 21:20:07 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19qJKI-0001NG-Ll; Fri, 22 Aug 2003 17:20:06 -0400 Date: Fri, 22 Aug 2003 21:20:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Cc: Ingo Molnar Subject: Re: [commit] Last major piece of fork tracing - vfork/exec Message-ID: <20030822212006.GA5238@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com, Ingo Molnar References: <20030817201922.GA10584@nevyn.them.org> <3F40F4BF.5020702@redhat.com> <3F46378F.1000102@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F46378F.1000102@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00407.txt.bz2 On Fri, Aug 22, 2003 at 11:32:31AM -0400, Andrew Cagney wrote: > >> This patch is the last major piece of fork tracing: support for vfork and > >>exec. I have not enabled the code in infrun which attempts to > >>automatically > >>load the new executable, because I'm not happy with how it works, and > >>because it isn't necessary for this to be useful. > >> > >>I'll move this to the branch in a day or two if there are no problems. > >>I suppose fixing up the expected output in the testsuite is next... > >> > > >Please don't. The only things I know of still going down for 6.0 are some > >testsuite mangling and a re-fix for the red zone. > > > >Anything else can go in 6.1. > > > >My core file stuff, for instance, isn't in 6.0. > > Daniel, > > I'm really disappointed by the situtation you've created here. You, by > at the last moment trying to add this new functionality to 6.0 branch, > have effectively pushed me into a corner. I've got the following choices: > > - yank the existing code > invalidates relevant tests > as the release manager, I get the blame for delaying both the new > feature and the release > > - leave the code as is > Again, I get the blame for the feature not being present (after all it > is just wafer thin and won't have any affect on all the test results > that people have been doing up-until now, right?) > > - let the change in > invalidating test results > again delay the release ... > > Against my better judgment, I've decided to go with option 3. You can > commit this change but the release is delayed an extra week. Once again, my apologies for creating this entire situation. I've checked the patch in on the branch, after testing on an RH9 update kernel, a stock 2.4 kernel, and a 2.6 kernel. The tracing correctly reports itself as unavailable on stock 2.4, and correctly works on 2.6. On the RH kernel, fork tracing works, but vfork tracing (with parent follow) appears to have some problems - it looks as if Ingo merged my ptrace patches but missed a couple of bits. Notably in kernel/fork.c and fs/exec.c - the kernel reports support for VFORKDONE and EXEC events, but will not report them. GDB's behavior is still a strict improvement from before the patch, since breakponts are correctly removed from the child before it runs. Red Hat may wish to correct the issue, however. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer