Re: Understanding GDB frames

[Jim Blandy <jimb at codesourcery dot com>]

Ross Morley <ross@tensilica.com> writes:
> Jim Blandy wrote:
>
>>Maxim Grigoriev <maxim@tensilica.com> writes:
>>  
>>
>>>>All those frames ought to be different, but GDB will treat
>>>>some of them as the same.
>>>>      
>>>>
>>>I think distinguishing frames can be improved by using the third
>>>argument of frame_id, which is a "special address". Most of the
>>>implementations don't use it.
>>>    
>>>
>>
>>Yes --- that was meant for use by the IA-64, which has a separate
>>stack for saving registers.  If you have a series of calls with frames
>>holding nothing but saved registers, then they may allocate no space
>>at all on the ordinary stack.  So you need to use the register stack
>>pointer to distinguish frames, too.
>>
>>After I'd sent my last post I realized that, of course, the "entry
>>point PC" approach fails in the (I'd guess) more common case that the
>>"return address PC" does not:
>>
>>    void foo (void) {}
>>    main () { foo (); foo (); }
>>
>>Perhaps the best approach is to use both the return address and the
>>entry point in the frame ID.  If either have changed, it's certainly a
>>new frame.
>>  
>>
> Well not quite certainly, eg.
>
>    void bar (void) {}
>    void foo (void) { bar (); }
>    main () { foo (); foo (); }
>
> But definitely an improvement that's easy to achieve.

I don't follow.  Is there something here where a frame's return
address and entry point change, but it's not a new frame?  I'm not
claiming using both the return address and the entry point would
eliminate false positives in frame_eq, just that it restricts false
positives and does not introduce false negatives.