From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24354 invoked by alias); 24 Jan 2012 13:20:00 -0000 Received: (qmail 24346 invoked by uid 22791); 24 Jan 2012 13:19:59 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Jan 2012 13:19:36 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0ODJan9025327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jan 2012 08:19:36 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0ODJYWw026861; Tue, 24 Jan 2012 08:19:35 -0500 Message-ID: <4F1EAFE6.30202@redhat.com> Date: Tue, 24 Jan 2012 13:40:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: [patch 2/2] Fix watchpoints for multi-inferior #2 References: <20120102164652.GB10231@host2.jankratochvil.net> <4F02020F.5090906@gmail.com> <20120120213110.GB424@host2.jankratochvil.net> In-Reply-To: <20120120213110.GB424@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-01/txt/msg00819.txt.bz2 On 01/20/2012 09:31 PM, Jan Kratochvil wrote: > On Mon, 02 Jan 2012 20:14:23 +0100, Pedro Alves wrote: >> Do we clear inf_data or inf_data's contents anywhere on inferior >> exit or startup, so to not leave debug registers stale across runs? >> (The cleanup only runs when the inferior is deleted.) > > Yes, it is already cleared in FSF GDB. Good, thanks. > Plus I think this issue is unrelated to this multi-inferiorization patch. It would be if the multi-inferiorization would make debug registers stale, hence my question. Please try to keep an open spirit. > >>> --- /dev/null >>> +++ b/gdb/testsuite/gdb.multi/watchpoint-multi.exp > [...] >>> +if [is_remote target] { >>> + # It is KFAIL. >>> + continue >> >> Did you mean to turn this into a real kfail? What are the >> gdbserver problems, btw? > > It is no longer KFAIL, included gdbserver fixes. > > The first one is for dead-loop of: > Got an event from pending child 10373 (057f) > Got a pending child 10373 > Got an event from pending child 10373 (057f) > Got a pending child 10373 > because linux_wait_for_event creates creates status_pending_p and then asks > linux_wait_for_event_1 for the next event which apparently returns the newly > created status_pending_p so linux_wait_for_event stores it back and so on. > > The second fix is that despite default `set schedule-multiple off' gdbserver > sometimes resumed all the inferiors on GDB "continue". > > Both cases are visible with the testcase (the first one in ~50% of runs). Ah. Could you please split the gdbserver bits into a separate patch? I'd like to take a good look at them, but if the watchpoint bits proper are already in, it'd be easier. The non-gdbserver bits look okay to me. > /* Count the LWP's that have had events. */ > > static int > @@ -2107,7 +2090,14 @@ retry: > if (thread == NULL) > { > struct thread_resume resume_info; > - resume_info.thread = minus_one_ptid; > + > + /* Resume only a single process if requested so. */ > + if (!ptid_equal (cont_thread, minus_one_ptid) > + && ptid_get_lwp (cont_thread) == -1) > + resume_info.thread = cont_thread; Just above we see: thread = (struct thread_info *) find_inferior_id (&all_threads, cont_thread); /* No stepping, no signal - unless one is pending already, of course. */ if (thread == NULL) So, cont_thread does not exist, which was the whole point of reaching here. Therefore there's no use trying to resuming it (at first sight). BTW, I have just recently stumbled on this: http://sourceware.org/ml/gdb-patches/2012-01/msg00502.html But as said, I'll need to take a better look at the gdbserver bits. > + else > + resume_info.thread = minus_one_ptid; > + > resume_info.kind = resume_continue; > resume_info.sig = 0; > linux_resume (&resume_info, 1); -- Pedro Alves