From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14404 invoked by alias); 25 Jan 2012 18:04:09 -0000 Received: (qmail 14394 invoked by uid 22791); 25 Jan 2012 18:04:08 -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 18:03:54 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0PI3shG020822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 25 Jan 2012 13:03:54 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q0PI3qMM005495; Wed, 25 Jan 2012 13:03:53 -0500 Message-ID: <4F204408.4090607@redhat.com> Date: Wed, 25 Jan 2012 18:22: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: gdb-patches@sourceware.org CC: Jan Kratochvil 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> <4F203B6A.7090605@redhat.com> In-Reply-To: <4F203B6A.7090605@redhat.com> 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/msg00871.txt.bz2 On 01/25/2012 05:27 PM, Pedro Alves wrote: > 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. Bah, no, it is still not sufficient. Don't know why it passed for me before. Looking again... > 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. -- Pedro Alves