From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31738 invoked by alias); 31 Oct 2008 00:25:40 -0000 Received: (qmail 31001 invoked by uid 22791); 31 Oct 2008 00:25:38 -0000 X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 31 Oct 2008 00:23:37 +0000 Received: from exch4.caveonetworks.com (Not Verified[192.168.16.23]) by mail3.caviumnetworks.com with MailMarshal (v6,2,2,3503) id ; Thu, 30 Oct 2008 20:23:26 -0400 Received: from exch4.caveonetworks.com ([192.168.16.23]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:23:25 -0700 Received: from dd1.caveonetworks.com ([64.169.86.201]) by exch4.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 17:23:25 -0700 Message-ID: <490A4FFD.2070806@caviumnetworks.com> Date: Fri, 31 Oct 2008 02:13:00 -0000 From: David Daney User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Joel Brobecker CC: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [Patch] Use resume instead of target_resume when stepping over watchpoint. References: <48C71565.3050601@avtrex.com> <20081030030805.GC3635@adacore.com> <200810301222.23864.pedro@codesourcery.com> <20081030152933.GE13387@adacore.com> In-Reply-To: <20081030152933.GE13387@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2008-10/txt/msg00717.txt.bz2 Joel Brobecker wrote: > [Dave Daney removed from the list, since his email address is no longer > valid. Is it worth pursuing this thread?] > It turns out that I am now subscribed under my new e-mail address. But thanks to Tom Tromey for pinging me on this message. >> Won't this slightly change the behaviour on hardware single-step >> archs? Before, we'd always tell the target to resume a single-thread >> (keeping the others stopped, on target that support scheduler locking); >> with this change, I think you'll tell the target to resume all >> threads. > > Hmmm, yes, you're probably right. I we were to set trap_expected, > then we would only step that one thread, but would that be cheating? > >> be too ugly? Hmmm, maybe not OK, it can have other side >> effects, like tripping on this... >> >> if (ecs->event_thread->stop_signal == TARGET_SIGNAL_TRAP >> && ecs->event_thread->trap_expected >> && gdbarch_single_step_through_delay_p (current_gdbarch) >> && currently_stepping (ecs->event_thread)) > > I guess we might, if we hit the watchpoint while stepping. But then, > trap_expected would have already been set, and thus we'd be OK without > setting it anyways. > > Regardless, I think this just shows that calling resume like this is > just too ugly. Perhaps a better approach would be to extract out the > part that handles software_single_step out of resume and have both > resume & handle_inferior_event call that new function? > I agree, and in the first version of the patch I hacked something together that kind of did it that way, but it was not very clean. Now that the MIPS hardware watch register support is merged into the Linux kernel, my plans are to pursue this patch set further. Unfortunately I am waiting for action out of the FSF copyright clerk so that I can update my employer disclaimer. The patch is not forgotten. Previously I was working on it to make my own life a litter easier, but now I have an actual mandate to work on it. David Daney