From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1128 invoked by alias); 28 May 2014 19:19:18 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 1111 invoked by uid 89); 28 May 2014 19:19:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 May 2014 19:19:16 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4SJJDt8002351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 May 2014 15:19:13 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4SJJBeh007782; Wed, 28 May 2014 15:19:12 -0400 Message-ID: <538636AF.9040208@redhat.com> Date: Wed, 28 May 2014 19:19:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Hui Zhu , gdb-patches ml Subject: Re: [PATCH] Fix gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) (timeout) with Linux 2.6.32 and older version References: <533D17E2.9070402@mentor.com> In-Reply-To: <533D17E2.9070402@mentor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-05/txt/msg00700.txt.bz2 On 04/03/2014 09:12 AM, Hui Zhu wrote: > Got gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) > (timeout) with Linux 2.6.32 and older version. > > The rootcause is after the test use "set can-use-hw-watchpoints 0" let GDB > doesn't use hardware breakpoint and set a watchpoint on "global", GDB > continue will keep single step inside function "vfork". > The Linux 2.6.32 and older version doesn't have commit > 6580807da14c423f0d0a708108e6df6ebc8bc83d (get more info please goto > http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=6580807da14c423f0d0a708108e6df6ebc8bc83d). > When the function "vfork" do syscall, the single step flag TIF_SINGLESTEP > will copy to child process. > Then GDB detach it, child process and parent process will be hanged. > > So I make a patch that do a single step before detach. Then TIF_SINGLESTEP > of child process in old Linux kernel will be cleared before detach. > Child process in new Linux kernel will not be affected by this single step. > > The patch was tested and pass regression in new linux > kernel (3.13.6-200.fc20.x86_64) and old Linux kernel (2.6.32-38-server). > > Please help me review it. Thanks. > 2014-04-03 Hui Zhu > > * linux-nat.c (linux_child_follow_fork): do a single step before > detach. > > --- a/gdb/linux-nat.c > +++ b/gdb/linux-nat.c > @@ -442,6 +442,26 @@ holding the child stopped. Try \"set de > > if (linux_nat_prepare_to_resume != NULL) > linux_nat_prepare_to_resume (child_lp); > + > + /* When debug a inferior in the architecture that support > + hardware single step and the Linux kernel without commit > + 6580807da14c423f0d0a708108e6df6ebc8bc83d, the vfork child > + process will starts with TIF_SINGLESTEP/X86_EFLAGS_TF bits > + if the parent process has it. > + So let child process do a single step under GDB control > + before detach it to remove this flags. */ >From the kernel patch's looks, this doesn't sound like architecture specific, otherwise I'd suggest clearing TF instead. So it sounds like a good solution. I suggested this updated comment, copy/edited a bit from yours: /* When debugging an inferior in an architecture that supports hardware single stepping on a kernel without commit 6580807da14c423f0d0a708108e6df6ebc8bc83d, the vfork child process starts with the TIF_SINGLESTEP/X86_EFLAGS_TF bits set if the parent process had them set. To work around this, single step the child process once before detaching to clear the flags. */ > + > + if (!gdbarch_software_single_step_p (target_thread_architecture > + (child_lp->ptid))) > + { > + int status; > + > + if (ptrace (PTRACE_SINGLESTEP, child_pid, 0, 0) < 0) > + perror_with_name (_("Couldn't do single step")); > + if (my_waitpid (child_pid, &status, 0) < 0) > + perror_with_name (_("Couldn't wait vfork process")); If the child gets a signal here, we should pass it on to the child. > + } > + > ptrace (PTRACE_DETACH, child_pid, 0, 0); That is: ptrace (PTRACE_DETACH, child_pid, 0, WSTOPSIG (status)); And I think we should disable all ptrace options in the child before stepping it, in case some event is reported right at that point, and we mishandle it. Otherwise we'd need to make sure we didn't get an extended wait status before passing it on. But disabling events is just safer. > > do_cleanups (old_chain); > -- Pedro Alves