From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10792 invoked by alias); 13 Oct 2010 07:23:59 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 10782 invoked by uid 22791); 13 Oct 2010 07:23:58 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Oleg Nesterov X-Fcc: ~/Mail/utrace CC: utrace-devel@redhat.com, archer@sourceware.org Subject: Re: gdbstub initial code, v7 In-Reply-To: Oleg Nesterov's message of Friday, 10 September 2010 21:20:01 +0200 <20100910192001.GA30490@redhat.com> References: <20100830185850.GA1132@redhat.com> <20100830192040.GA15431@host1.dyn.jankratochvil.net> <20100831072048.GA26362@host1.dyn.jankratochvil.net> <20100902200632.GA23692@redhat.com> <20100903064008.GA16249@host1.dyn.jankratochvil.net> <20100903230957.GC8917@redhat.com> <20100910101452.39015405D5@magilla.sf.frob.com> <20100910182903.GB27699@redhat.com> <20100910190547.85CBD405D5@magilla.sf.frob.com> <20100910192001.GA30490@redhat.com> Message-Id: <20101013072346.1F239401B2@magilla.sf.frob.com> Date: Wed, 13 Oct 2010 07:23:00 -0000 X-SW-Source: 2010-q4/txt/msg00014.txt.bz2 > On 09/10, Roland McGrath wrote: > > > > > ugdb sets "please stop" flag and does utrace_control(INTERRUPT). However, > > > in unlikely case the tracee can stop before ->report_signal() reporting > > > > I don't think this is the right thing to do. When the intent is explicitly > > to interrupt, there is no reason to stop before the interruption is > > complete, i.e. report_signal. > > This means that ugdb_report_quiesce() should never return UTRACE_STOP, > and that is all. I'm not sure about this. > But what about multitracing? Suppose that "(gdb) interrupt" happens > just before, say, do_report_syscall_entry() and another engine wants > to stop. If ugdb_report_quiesce() doesn't return UTRACE_STOP, then > gdb will wait until another debugger resumes the tracee. Yes, I do think that's a problem. We want gdb to report back promptly. One possibility is to have report_quiesce notice its argument is UTRACE_EVENT(SYSCALL_ENTRY) and roll back to before the syscall. That is, it enables SYSCALL_ENTRY and SYSCALL_EXIT reporting, then its report_syscall_entry uses UTRACE_SIGNAL_ABORT, report_syscall_exit does syscall_set_return_value(-ERESTARTNOHAND, 0) and then returns UTRACE_INTERRUPT. Now, we'll reenter a UTRACE_SIGNAL_REPORT callback "before" the system call, and we can stop there without being in any sticky situation. Thanks, Roland