From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16579 invoked by alias); 31 Mar 2003 17:16:49 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16554 invoked from network); 31 Mar 2003 17:16:45 -0000 Received: from unknown (HELO molenda.com) (192.220.74.81) by sources.redhat.com with SMTP; 31 Mar 2003 17:16:45 -0000 Received: (qmail 43047 invoked by uid 19025); 31 Mar 2003 17:22:03 -0000 Date: Mon, 31 Mar 2003 17:16:00 -0000 From: Jason Molenda To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: Adding -file-list-exec-source-file command to GDB/MI Message-ID: <20030331092203.A40264@molenda.com> References: <20030320224454.GA14096@white> <20030321015532.A54903@molenda.com> <20030321131614.GA14884@white> <3E846994.3040708@redhat.com> <20030330040652.GA8455@white> <3E87C26B.5060102@redhat.com> <20030331001815.A647@molenda.com> <3E885148.6050401@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E885148.6050401@redhat.com>; from ac131313@redhat.com on Mon, Mar 31, 2003 at 09:31:36AM -0500 X-SW-Source: 2003-03/txt/msg00609.txt.bz2 On Mon, Mar 31, 2003 at 09:31:36AM -0500, Andrew Cagney wrote: > > > -stack-list-frames > > ^done,stack=[frame={level="0",addr="0x00001dc8",fp="0xbffffca0",func="foo",file="f/a.c",line="3",dir="/tmp/e/"}, [...] > > [...] > > > The other difference is the addition of FP here -- our UI uses the > > PC and FP to uniquely identify stack frames > > That doesn't work. The MI needs to be updated so that it uses frame > ID's when identifying frames. Uh, we have a bit of an existance proof that it does--in the form of a PB+GDB that have been shipping like this for over a year. I don't mean to indicate that this is the only thing the UI does, but after an exec-next I think the sequence is something like - retrieve frame #0 and #1, get the depth of the stack, send a stack-list-frames-lite command (which returns just the PC and FP for the frames - filling out the stack frame cache is really expensive for a big application with a deep stack.) I don't remember the exact sequence offhand, but that's basically it. Our last source merge was early in your frame cache reworkings, and we won't have another merge until we branch off for our next release, so we can't look at using it for this release. (the stack-list-frames-lite is recognized as a hack that is not relevant in the face of all your frame code reworkings; I expect we'll be switching over first thing after this release branches.) Jason