From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21426 invoked by alias); 7 Apr 2006 17:36:32 -0000 Received: (qmail 21417 invoked by uid 22791); 7 Apr 2006 17:36:32 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Apr 2006 17:36:29 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k37HaHPt009176; Fri, 7 Apr 2006 10:36:17 -0700 (PDT) Received: from [17.201.22.240] (unknown [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id 1639E3B8; Fri, 7 Apr 2006 10:36:17 -0700 (PDT) In-Reply-To: <200604070954.14083.ghost@cs.msu.su> References: <200602171724.03824.ghost@cs.msu.su> <200604061703.26246.ghost@cs.msu.su> <3D7DB938-8B8A-4DE9-BA5B-2E2F56DA24D7@apple.com> <200604070954.14083.ghost@cs.msu.su> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3657EE52-4544-435A-A842-06EC44FFDA41@apple.com> Cc: GDB List Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: type prefixes for values Date: Fri, 07 Apr 2006 20:08:00 -0000 To: Vladimir Prus X-IsSubscribed: yes 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/msg00107.txt.bz2 Yes, it looks like we added that. Our -stack-list-frames looks like: 553^done,stack=[frame= {level="0",addr="0x00003db0",fp="0xbffff2c0",func="main",file="/ private/nfsroot/Users/jingham/Projects/ManyThreads/main.m",fullname="/ private/nfsroot/Users/jingham/Projects/ManyThreads/ main.m",line="64",dir="/private/nfsroot/Users/jingham/Projects/ ManyThreads/"}] Jim On Apr 6, 2006, at 10:54 PM, Vladimir Prus wrote: > 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