From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5948 invoked by alias); 17 Oct 2008 05:46:16 -0000 Received: (qmail 5934 invoked by uid 22791); 17 Oct 2008 05:46:15 -0000 X-Spam-Check-By: sourceware.org Received: from ti-out-0910.google.com (HELO ti-out-0910.google.com) (209.85.142.188) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Oct 2008 05:45:40 +0000 Received: by ti-out-0910.google.com with SMTP id d10so189904tib.12 for ; Thu, 16 Oct 2008 22:45:36 -0700 (PDT) Received: by 10.110.41.17 with SMTP id o17mr2654438tio.27.1224222336256; Thu, 16 Oct 2008 22:45:36 -0700 (PDT) Received: by 10.110.42.9 with HTTP; Thu, 16 Oct 2008 22:45:36 -0700 (PDT) Message-ID: Date: Fri, 17 Oct 2008 05:46:00 -0000 From: teawater To: "Michael Snyder" Subject: Re: [RFA] Displaced stepping just enable in non-stop mode Cc: "Eli Zaretskii" , pedro@codesourcery.com, gdb-patches@sourceware.org, brobecker@adacore.com In-Reply-To: <48F7AEF2.4050405@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200810160107.42525.pedro@codesourcery.com> <20081016123422.GA31057@caradoc.them.org> <20081016183217.GA27176@caradoc.them.org> <48F7AEF2.4050405@vmware.com> 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/msg00422.txt.bz2 On Fri, Oct 17, 2008 at 05:15, Michael Snyder wrote: > 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... > > How about "set step displace" I think "displace" is clear.