From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19344 invoked by alias); 17 May 2003 03:39:12 -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 19070 invoked from network); 17 May 2003 03:39:06 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 17 May 2003 03:39:06 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BFE452B2F; Fri, 16 May 2003 23:38:51 -0400 (EDT) Message-ID: <3EC5AECB.1080106@redhat.com> Date: Sat, 17 May 2003 03:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , Kris Warkentin Cc: Quality Quorum , "Gdb@Sources.Redhat.Com" Subject: Re: (remote) hellishly slow single stepping over library calls References: <075801c31be0$c5d0de10$0202040a@catdog> <20030516192900.GA2984@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00258.txt.bz2 > On Fri, May 16, 2003 at 03:24:30PM -0400, Kris Warkentin wrote: > >> > > Would this problem also exist with the normal remote protocol? (stupid >> > > users...clicking step instead of next....;-) > >> > >> > What about using the T-format with a value of PC to report status, instead >> > of using the S-format, for the purpose. > >> >> We're not using gdb's remote protocol but rather our own. I see from >> remote.c though that T-format is just an expedited reply with just a signal >> and the appropriate registers. I'm assuming that each target would be in >> charge of knowing what it needs to put in these replies and when to use >> them. > > > Yes, that's how it works. > > >> I'll look into implementing that sort of thing on our end. > > > It should be pretty straightforward to do. When you get the right > registers, it's quite effective, too. Something useful here would be a mod to regcache.[hc] to track the registers requested (after a flush/invalidate) (via regcache_raw_read) rather than the registers supplied (via supply_register) (displayed via maint print raw-registers) That, and a few single steps, would pretty quickly tell you what is needed. The other way is to watch the output of 'set debug target'. Andrew