From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13881 invoked by alias); 5 Dec 2009 03:50:02 -0000 Received: (qmail 13799 invoked by uid 22791); 5 Dec 2009 03:50:00 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f211.google.com (HELO mail-ew0-f211.google.com) (209.85.219.211) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Dec 2009 03:49:53 +0000 Received: by ewy3 with SMTP id 3so78358ewy.13 for ; Fri, 04 Dec 2009 19:49:50 -0800 (PST) Received: by 10.213.79.66 with SMTP id o2mr10885021ebk.22.1259984990692; Fri, 04 Dec 2009 19:49:50 -0800 (PST) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 7sm6263770eyg.9.2009.12.04.19.49.48 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Dec 2009 19:49:49 -0800 (PST) Message-ID: <4B19DC20.907@gmail.com> Date: Sat, 05 Dec 2009 03:50:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Dave Korn , gdb@sourceware.org Subject: Re: Software-vs-hardware single-step vs. sim/non-sim targets. References: <4B197BC0.5010708@gmail.com> <20091204220825.GA12336@caradoc.them.org> In-Reply-To: <20091204220825.GA12336@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-12/txt/msg00035.txt.bz2 Daniel Jacobowitz wrote: [ out-of-order: > There's no obvious easy solution to this, but the basic problem has > been discussed many times. Sorry for making you go over old ground; it's not easy to get good search results with terms as general as "hardware software single step gdb"; I wouldn't be offended if you replied with just a couple of words for better search terms or URLs to earlier threads. ] > Answering the last question first, no, it does not necessarily get called. > IMO the remote protocol hook you need is already present: implement > vCont, even though it's overkill for an embedded single-threaded > processor. Report that you don't support s or S in the vCont? reply. > > Current GDB will choke. So you have to somehow separate the above > questions, so that when we ask the architecture whether to > single-step, it knows whether the target needs SSS or not. Hmm, okay, so the arch doesn't get re-inited between detaching from one target and attaching to the next. But I'd bet (and I mean bet, I haven't looked yet, but I can't imagine how the whole thing hangs together if it doesn't work this way) that the infrun state machine does get thoroughly and properly reset and all in-memory breakpoints restored during the detach/reattach sequence. So in theory it should all be ok if gdbarch_software_single_step_p() returned different values dynamically, so long as they're constant during any given run of the inferior. Maybe it would work to turn that into an arch hook, with a default that works like the current version by simply testing if the single_step hook is set, but allow for a dynamically-varying version to be installed by arches that choose. I'll look a bit at how well that would work. (Ah, gdbarch_software_single_step_p makes an instructive search term, there seems to have been some discussion about what to do round the time when the macro version got replaced by a hook. Haven't yet found anything that looks like a firm resolution to it though.) cheers, DaveK