From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12177 invoked by alias); 19 Oct 2010 19:24:14 -0000 Received: (qmail 12161 invoked by uid 22791); 19 Oct 2010 19:24:12 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Oct 2010 19:24:08 +0000 Received: (qmail 26204 invoked from network); 19 Oct 2010 19:24:06 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Oct 2010 19:24:06 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc] linux-nat: Never PTRACE_CONT a stepping thread Date: Tue, 19 Oct 2010 19:24:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.33-29-realtime; KDE/4.4.2; x86_64; ; ) Cc: Jan Kratochvil References: <20100921234325.GA31267@host1.dyn.jankratochvil.net> <201010172004.18986.pedro@codesourcery.com> <20101018085138.GA25628@host1.dyn.jankratochvil.net> In-Reply-To: <20101018085138.GA25628@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010192024.04881.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2010-10/txt/msg00299.txt.bz2 On Monday 18 October 2010 09:51:38, Jan Kratochvil wrote: > On Sun, 17 Oct 2010 21:04:18 +0200, Pedro Alves wrote: > > I just belatedly realized that this probably > > breaks software single-step archs though. :-/ > > I have run the testsuite on arm-fedora12-linux-gnu and the only (...) Thanks for testing. Does the new test pass there? What I actually remembered was that using PTRACE_SINGLESTEP, and leaving lwp->step true on software single-step archs probably isn't a good idea. And it crossed my mind that we'd probably need to make infrun.c know it needs to insert software single-step breakpoint in this case too. > I do not see why it should fail in general. insert_single_step_breakpoint > already supports two existing single step breakpoints, one gets used for > inferior_ptid and one for stepping ptid. But hmm, you left me confused. In the case at hand, from reading the code, by the time you get to linux_nat_resume, infrun.c has context-switched inferior_ptid to the thread that we're "delivering" the signal to. Right after context-switching, infrun pulled the previous single-step breakpoints out of target: if (singlestep_breakpoints_inserted_p) { /* Pull the single step breakpoints out of the target. */ remove_single_step_breakpoints (); singlestep_breakpoints_inserted_p = 0; } when handle_inferior_event handles the random signal, and decides to forward it to the target, it calls keep_going, which then calls resume, passing it currently_stepping(ecs->event_thread). ecs->event_thread was _not_ stepping, so _no_ single step breakpoints are inserted in the target. I'm following this only by reading the code, but since I see: "vCont;C1e:795a;s:7959;c" coming out, and not "vCont;S1e:795a;s:7959;c" I'm led to believe the analysis is correct. > Maybe the support of two single step > breakpoints is there for some inferior code constructs, in such case > I understand two would be no longer enough. Yes, there are constructs where we need two breakpoints, usually in cases related to conditional branching where we can't tell whether the branch will be taken or not, so we need one breakpoint at the branch destination and a breakpoint after the branch instruction. Grepping for insert_single_step_breakpoint will find all cases. I'm also wondering if tweaking the test to use a signal less than SIGTRAP (5) rather than SIGUSR1 (10) so that waitpid always picks it up over SIGTRAP if both are pending simulateneously reveals that we need to rethink this? -- Pedro Alves