From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14870 invoked by alias); 7 Apr 2006 05:54:32 -0000 Received: (qmail 14861 invoked by uid 22791); 7 Apr 2006 05:54:31 -0000 X-Spam-Check-By: sourceware.org Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Apr 2006 05:54:27 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1FRjvK-0006BR-V1 for gdb@sources.redhat.com; Fri, 07 Apr 2006 09:54:24 +0400 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1FRjvD-00068w-6g; Fri, 07 Apr 2006 09:54:15 +0400 From: Vladimir Prus To: Jim Ingham Subject: Re: MI: type prefixes for values Date: Fri, 07 Apr 2006 08:13:00 -0000 User-Agent: KMail/1.7.2 Cc: GDB List References: <200602171724.03824.ghost@cs.msu.su> <200604061703.26246.ghost@cs.msu.su> <3D7DB938-8B8A-4DE9-BA5B-2E2F56DA24D7@apple.com> In-Reply-To: <3D7DB938-8B8A-4DE9-BA5B-2E2F56DA24D7@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200604070954.14083.ghost@cs.msu.su> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00088.txt.bz2 On Thursday 06 April 2006 20:53, Jim Ingham wrote: > > The case I'm not sure about is this: > > > > 1. main calls 'a' which calls 'b' which bits breakpoint. > > 2 varobj is created for local var of 'b' > > 3. Users says 'continue'. > > 4. 'b' exists and then 'a' calls 'b' again and breakpoint is > > hit again. > > > > However, this second time it's not guaranteed that stack frame of > > 'b' is at > > the same address as it was the last time -- maybe 'a' has pushed > > something on > > stack. How do you detect this case? > > I said this in another response, but to be clear, Xcode stores the > frame_id's from each stack frame when it stops. It holds onto this, > and when it stops again it checks this fingerprint against the new > frame id's, and the throws away all the varobj's from the point the > frame_id's vary on to the bottom of stack. There's no ambiguity if > you do this. Then, Xcode has to get frame_id of the current frame from gdb, right? Where frame is is (stack address + code address). The code address is readily available, but I see no way to get stack address. Is that something you've added? - Volodya