From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17192 invoked by alias); 23 Feb 2002 01:05:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 17017 invoked from network); 23 Feb 2002 01:05:54 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 23 Feb 2002 01:05:54 -0000 Received: from redhat.com (notinuse.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA08552; Fri, 22 Feb 2002 17:05:46 -0800 (PST) Message-ID: <3C76E8F3.673C6559@redhat.com> Date: Fri, 22 Feb 2002 17:05:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: "Frank Ch. Eigler" , cagney@redhat.com CC: sid@sources.redhat.com, gdb@sources.redhat.com Subject: Re: sid debugger interface extension: step out-of-range packet support References: <20020212171421.D13536@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-02/txt/msg00269.txt.bz2 "Frank Ch. Eigler" wrote: > > Hi - > > A small amount of new code in sid/include and sid/component/gdb > now allows gdb's "step out-of-range" packet ('e'/'E') to work with > all sid-based simulator targets. This packet makes remote debugging > potentially significantly faster, because it can replace a sequence of > instruction single-step packets with just one new packet. This finally > exercises J.T. Conklin's gdb-side extensions from roughly a year ago. > > There is a gdb bug that is exposed by this support. If a breakpoint > placed on the current instruction, and another one on the next > source line, then letting gdb "step" will stop at the next line, but > won't let gdb realize that the second breakpoint was hit. (This is > because gdb never inserted the breakpoints in gdb/infrun.c's proceed(), > being unaware that remote_resume() meant something other than stepi.) > This looks like this is a minor problem, but just in case, support for > the packet may be forced off from the gdb side and/or from the sid side. Thanks for pointing out this problem, which is in fact more severe than you think. A quick experiment reveals that if you 1) put a breakpoint at the beginning of line N 2) put a second breakpoint in the MIDDLE of line N 3) attempt to step over line N the second breakpoint will not be hit. And in fact, if you have a multi-threaded program, all threads will have the opportunity to run (if they are runnable), and NONE of them will hit ANY breakpoints while we are executing line N. This will give threads the opportunity to "run away".