This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Understanding GDB frames
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.