From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18335 invoked by alias); 9 Sep 2010 12:39:43 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 18265 invoked by uid 22791); 9 Sep 2010 12:39:41 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org To: Oleg Nesterov Cc: archer@sourceware.org, utrace-devel@redhat.com Subject: Re: gdbstub initial code, v9 References: <20100908191838.GA27120@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 09 Sep 2010 12:39:00 -0000 In-Reply-To: <20100908191838.GA27120@redhat.com> (Oleg Nesterov's message of "Wed, 8 Sep 2010 21:18:38 +0200") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2010-q3/txt/msg00159.txt.bz2 Oleg Nesterov writes: > [...] > But, Jan. Implementing the memory writes does not mean breakpoints > automatically start to work! It approximately should though. > Yes, gdb writes cc, and yes the tracee reports SIGTRAP. But after > that "continue" does nothing except "$c", and the tracee naturally > gets SIGILL. I expected that, since ugdb doesn't even know the code > was changed, gdb should write the original byte back before continue, > but this doesn't happen. In normal all-stop mode, gdb does normally replace the old instruction, in order to single-step over it with the 's' packet. Perhaps you're testing some buggy non-stop aspect that only works with 'Z' breakpoint management packets? A fuller packet trace would help explain. - FChE