From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9282 invoked by alias); 25 Jan 2012 17:27:36 -0000 Received: (qmail 9271 invoked by uid 22791); 25 Jan 2012 17:27:35 -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; Wed, 25 Jan 2012 17:27:08 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0PHR7Gl030869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2012 12:27:07 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0PHR6Dn010127; Wed, 25 Jan 2012 12:27:06 -0500 Message-ID: <4F203B6A.7090605@redhat.com> Date: Wed, 25 Jan 2012 17:54: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> <4F1EAFE6.30202@redhat.com> <20120125152240.GA26914@host2.jankratochvil.net> In-Reply-To: <20120125152240.GA26914@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/msg00869.txt.bz2 On 01/25/2012 03:22 PM, Jan Kratochvil wrote: > On Tue, 24 Jan 2012 14:19:34 +0100, Pedro Alves wrote: >> On 01/20/2012 09:31 PM, Jan Kratochvil wrote: >>> @@ -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. > > FYI I did not repost this patch part as it needs to be implemented by some > larger code rewrite IMO now, anyway this patch chunk is not good according to > your review. Yeah. That cont_thread bit should really go away. I've been looking at your other patch (the linux_wait_for_event_1 one), and seeing: (gdb) run Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.multi/watchpoint-multi handling possible serial event getpkt ("QDisableRandomization:1"); [no ack sent] [address space randomization disabled] putpkt ("$OK#9a"); [noack mode] handling possible serial event getpkt ("vRun;2f686f6d652f706564726f2f6764622f6d796769742f6275696c642f6764622f7465737473756974652f6764622e6d756c74692f7761746368706f696e742d6d756c7469"); [no ack sent] new_argv[0] = "/home/pedro/gdb/mygit/build/gdb/testsuite/gdb.multi/watchpoint-multi" Process /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.multi/watchpoint-multi created; pid = 21270 linux_wait: [Process 21270] pc is 0x40060f Need step over [LWP 21269]? yes, but found GDB breakpoint at 0x40060f; skipping step over Need step over [LWP 21270]? Ignoring, not stopped Resuming, no pending status or step over needed resuming LWP 21269 pc is 0x40060f Resuming lwp 21269 (continue, signal 0, stop not expected) resuming from pc 0x40060f resuming LWP 21270 linux_wait_for_lwp: And I had a wth moment -- Why are we resuming 21269 at all, since we just spawned 21270. I then realized that it is resumed exactly that by broken cont_thread code in linux_wait_1... I really would like to get back to getting rid of those cont_thread bits, but, this patch, very similar to the one linked above (which fixed it for vAttach), completely fixes this testcase as well. The issue is that cont_thread is also stale from the previous run, when we start a new vRun. So I think the patch below is correct, and should be applied. You patch may _also_ be correct, and necessary for other cases. I'll go back to staring at it. -- Pedro Alves 2012-01-25 Pedro Alves * server.c (start_inferior): Clear `cont_thread'. --- 0 files changed, 0 insertions(+), 0 deletions(-) diff --git a/gdb/gdbserver/server.c b/gdb/gdbserver/server.c index c1788a9..9c50ecc 100644 --- a/gdb/gdbserver/server.c +++ b/gdb/gdbserver/server.c @@ -259,6 +259,10 @@ start_inferior (char **argv) signal (SIGTTIN, SIG_DFL); #endif + /* Clear this so the backend doesn't get confused, thinking + CONT_THREAD died, and it needs to resume all threads. */ + cont_thread = null_ptid; + signal_pid = create_inferior (new_argv[0], new_argv); /* FIXME: we don't actually know at this point that the create