From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29636 invoked by alias); 31 Mar 2003 19:20:19 -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 29629 invoked from network); 31 Mar 2003 19:20:18 -0000 Received: from unknown (HELO molenda.com) (192.220.74.81) by sources.redhat.com with SMTP; 31 Mar 2003 19:20:18 -0000 Received: (qmail 75121 invoked by uid 19025); 31 Mar 2003 19:25:38 -0000 Date: Mon, 31 Mar 2003 19:20: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: <20030331112537.A73741@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> <20030331092203.A40264@molenda.com> <3E888E73.8050601@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: <3E888E73.8050601@redhat.com>; from ac131313@redhat.com on Mon, Mar 31, 2003 at 01:52:35PM -0500 X-SW-Source: 2003-03/txt/msg00614.txt.bz2 On Mon, Mar 31, 2003 at 01:52:35PM -0500, Andrew Cagney wrote: > >> > 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. > > Unfortunatly, that doesn't mean that it works: > > - it doesn't handle architectures with multiple stacks (ia64) > - it relies on $fp being constant through out the lifetime of the frame > (including the prologue) and that is definitly not true > - I suspect it is also making similar assumptions about $pc, it should > be using func. Ah, now I see. You didn't mean "That doesn't work", you meant "That doesn't work generally". #1 doesn't apply to us at Apple. #2 is a real problem - although the failure mode is that the UI re-fetches the stack, so it's not too traumatic. And because it only needs to re-fetch the 0th frame, it is fast. And you'll have the same problem with varobj's being deleted when your FP moves IIRC. As for #3, I don't understand why the PC won't remain constant for a frame other than the 0th, but you're familiar with far more architectures than me. Obviously the currently executing frame will have a changing PC, but the frames higher up on the stack should stay constant unless they've executed some more. Jason