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

Pedro Alves
2013-12-13T15:44:47Z

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