Re: MI: type prefixes for values

[Jim Ingham <jingham@apple.com>]

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