From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26662 invoked by alias); 16 Oct 2008 21:19:48 -0000 Received: (qmail 26654 invoked by uid 22791); 16 Oct 2008 21:19:48 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 16 Oct 2008 21:19:10 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 5E33C5C001; Thu, 16 Oct 2008 14:19:08 -0700 (PDT) Received: from [10.20.92.59] (promb-2s-dhcp59.eng.vmware.com [10.20.92.59]) by mailhost5.vmware.com (Postfix) with ESMTP id 53AE8DC05C; Thu, 16 Oct 2008 14:19:08 -0700 (PDT) Message-ID: <48F7AEF2.4050405@vmware.com> Date: Thu, 16 Oct 2008 21:19:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii , pedro@codesourcery.com, teawater@gmail.com, gdb-patches@sourceware.org, brobecker@adacore.com, msnyder@vmware.com Subject: Re: [RFA] Displaced stepping just enable in non-stop mode References: <200810160107.42525.pedro@codesourcery.com> <20081016123422.GA31057@caradoc.them.org> <20081016183217.GA27176@caradoc.them.org> In-Reply-To: <20081016183217.GA27176@caradoc.them.org> 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/msg00417.txt.bz2 Daniel Jacobowitz wrote: >> We could also try to detect if it works, and display a warning if we >> think it won't (RE the cases you described above). > > Hmm, that's an interesting idea. Pedro, what do you think - would > autodetection work for the cases we've seen trouble? Something as > simple as "can we write to _start" is probably enough, but I don't > remember what the failure looked like with the record target; and in > that case it may be complicated by the fact that we're initially going > forwards and could write. What it looks like is that you try to write to memory that's write-protected. This is because most replay targets will treat all of memory as write-protected when they are in replay mode. Where this usually manifests is, you'll say "continue" (probably for the first time since attaching to the target), and it'll croak because it's trying to step over some "invisible" breakpoint such as the one that handles shared libraries. > >>> I'm not sure what else to call displaced stepping. "Step around >>> breakpoints"? >> The text mentions "out-of-line stepping", which sounds better to me. > > I like "set step out-of-line"... Arr arr... step up-against-the-wall...