From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24068 invoked by alias); 17 Oct 2008 17:33:59 -0000 Received: (qmail 24060 invoked by uid 22791); 17 Oct 2008 17:33:58 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Oct 2008 17:33:23 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id E71904800B; Fri, 17 Oct 2008 10:33:21 -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 DD85BDC058; Fri, 17 Oct 2008 10:33:21 -0700 (PDT) Message-ID: <48F8CB7E.3060102@vmware.com> Date: Fri, 17 Oct 2008 17:33:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: Eli Zaretskii , "teawater@gmail.com" , "gdb-patches@sourceware.org" , "brobecker@adacore.com" Subject: Re: [RFA] Displaced stepping just enable in non-stop mode References: <20081016183217.GA27176@caradoc.them.org> <48F7AEF2.4050405@vmware.com> <200810171548.12752.pedro@codesourcery.com> In-Reply-To: <200810171548.12752.pedro@codesourcery.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/msg00438.txt.bz2 Pedro Alves wrote: > On Thursday 16 October 2008 22:15:30, Michael Snyder wrote: >> 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 see, then this means that all the reverse targets in existance > implement inserting breakpoints (target_insert_breakpoint, Z packet), > instead of relying on memory breakpoints. I believe that's true. Certainly it's true for gdb-freeplay. Teawater's "process replay" isn't a remote target, so it does not use Z packet explicitly, but it does something similar -- in effect, it mimics the Z0 semantics. VMware's development version uses Z0. > Ah, the record target > just ignores breakpoint insertions, and relies on forcing single-stepping > and checking breakpoint hits itself. That's right.