From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31715 invoked by alias); 4 Jun 2014 08:43:34 -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 31694 invoked by uid 89); 4 Jun 2014 08:43:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jun 2014 08:43:31 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1Ws6n9-0006bM-TR from Hui_Zhu@mentor.com ; Wed, 04 Jun 2014 01:43:27 -0700 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Jun 2014 01:43:27 -0700 Received: from localhost.localdomain (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.2.247.3; Wed, 4 Jun 2014 01:43:26 -0700 Message-ID: <538EDC2D.8050002@mentor.com> Date: Wed, 04 Jun 2014 08:43:00 -0000 From: Hui Zhu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pedro Alves , 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> <538636AF.9040208@redhat.com> In-Reply-To: <538636AF.9040208@redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00139.txt.bz2 On 05/29/14 03:19, Pedro Alves wrote: > 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. Could you give me some help on this part? I don't know how to disable all ptrace options. Thanks, Hui > >> >> do_cleanups (old_chain); >> >