Re: [patch v8 05/24] frame: artificial frame id's

[Pedro Alves <palves at redhat dot com>]

On 12/13/2013 12:59 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
>> owner@sourceware.org] On Behalf Of Pedro Alves
> 
> 
>> Take a look at this patch:
>>
>>   https://sourceware.org/ml/gdb-patches/2013-04/msg00541.html
>>
>> It seems to me your frames are exactly like those, though
>> it sounds like you may have more than one frame with stack
>> unavailable, and with the same code address, but that should
>> be identified as different frames (please confirm).  In that
>> case, it seems like you could use the artificial depth to
>> distinguish them.
> 
> I have several frames, none of them has an available stack.
> It's either my frames or some other frames.  They are never
> mixed.
> 
> I may also have frames with the same code address and they
> would need to be identified as different frames - confirmed.
> 
> I'm assigning a unique identifier to special so I can distinguish
> frames that have the same code address.  That identifier is
> preserved during stepping.

Thanks for the explanation.

> Afaik, the artificial depth is used for artificial frames beneath
> a real frame.  It's used for inline and tailcall frames.  The
> artificial_depth field is a simple counter.

Yes, I see that wouldn't work.  Too many assumptions around what
artificial_depth means all over.

> I could set stack_p to -1 instead of 0, though.  Looks like this
> already addresses some of the problems you listed.

Yeah.  Let me clean up that patch a little (and write a test
for it), and you should then able to build such frames, and
I don't think you'll need to change frame_id_eq then.

> Do you have tests that demonstrate the issues you mentioned?
> The tests in the repo behave identical with or without my changes.

For stepping around the program entry point, I don't think
there's any presently, and to trigger the issues, we'd need
to undo the hack in infrun.c at least.  The "tfind" case I
mention in the patch I pointed to is similar though ("tfind"
is kind of like "si" over trace frames).

-- 
Pedro Alves