From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14225 invoked by alias); 25 Jun 2008 14:15:05 -0000 Received: (qmail 14048 invoked by uid 22791); 25 Jun 2008 14:15:01 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Jun 2008 14:14:42 +0000 Received: (qmail 29472 invoked from network); 25 Jun 2008 14:14:40 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Jun 2008 14:14:40 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [RFA] set/show enable-software-singlestep Date: Wed, 25 Jun 2008 14:35:00 -0000 User-Agent: KMail/1.9.9 Cc: Joel Brobecker , Michael Snyder , Daniel Jacobowitz References: <1214331534.3601.1211.camel@localhost.localdomain> <1214335528.3601.1216.camel@localhost.localdomain> <20080625125424.GC3700@adacore.com> In-Reply-To: <20080625125424.GC3700@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200806251514.32422.pedro_alves@portugalmail.pt> 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-06/txt/msg00435.txt.bz2 A Wednesday 25 June 2008 13:54:24, Joel Brobecker wrote: > As discussed previously on gdb@, I think this is a useful feature > even outside of reverse debugging. Regarding Pedro's question > about making this feature transparent, that would be tough for > the example I gave, which is Tru64 - we want to be able to use > s/w single-step only on programs that use threads. To make it automatic, > we'd have to reliably detect that a program uses threads. Perhaps > this is doable, but having the option is an easy first step. Later > on, we can always extend the option to a tri-state with an "auto" > setting if it helps... I'm just curious about it, I can't figure which targets are used in Tru64. Is it ptrace based? =46rom your description of not being able to hw singlestep threaded programs, I take it threads are user space? I'm thinking what we want is the other way around. Can the target singlestep itself? Software-singlestepping with breakpoints is the current fallback mechanism. Is there a thread_stratum target used to implement the thread support? If so, we may be able to add a target_can_singlestep { yes/no } property/method and have the thread target return false, with the default implementation returning "false". - yes - the target takes care of singlestepping. for archs that don't have hw singlestep support, but the target (stub or kernel) handles it. That's what a Tru64 target should report. - no - even though the the kernel or stub (the debug API, that is) support single stepping, GDB should fake singlestepping if the arch doesn't support hw singlestepping. (usually by using=20 software-singlestepping breakpoints but emulating=20=20=20 instructions is another possibility, possible, e.g., we don't have to care about simulating exceptions.) This is the default, and corresponds to what we have currently). Just a quick thought dump. I'm not against the new knob. --=20 Pedro Alves