Re: [RFC] Python Finish Breakpoints

[Kevin Pouget <kevin.pouget@gmail.com>]

On Thu, Oct 20, 2011 at 10:41 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>
> Tom> You need to store a gdb.Type wrapper.
> Tom> A 'struct type' can also be invalidated when an objfile is destroyed.
>
> Kevin> I wouldn't mind, but I can't see how gdb.Type ensures validity, as far
> Kevin> as I've seen, there is no "is_valid" method and I can't and no further
> Kevin> verification during the Python -> C translation:
>
> When an objfile is destroyed, py-type.c:save_objfile_types is called.
> This makes a copy of the struct type underlying any relevant Type object.

I'll take a look at that, I don't remember what was the problem!

> [ out_of_scope_notif ]
> Kevin> - avoid calling `out_of_scope' every normal_stop when the breakpoint
> Kevin> is not anymore in the callstack
>
> It seems to me that manually managing this is not the best we could do.
>
> I was re-reading the code and I realized that this isn't actually
> working the way I had remembered it working:
>
> +A @fdb{finish breakpoint} is a breakpoint set at the return address of
> +a frame, based on the "finish command. @code{gdb.FinishBreakpoint} extends
> +@code{gdb.Breakpoint}
>
> This approach is fine; but once a frame is gone, it is gone -- we should
> just destroy the breakpoint at that point.  Maybe this would make the
> internal logic simpler as well.

yes, I think you're right with that, "once a frame is gone, it is
gone", I actually don't use myself this 'permanent finish breakpoint'
feature, so I'll change it.
So basically, the BP must be deleted right after it has been it (maybe
through the 'temporary' mechanism). 'out_of_scope' will be triggered
in the same conditions as before, but instead of playing with
'out_of_scope_notif' I'll delete the GDB breakpoint (thus invalidating
the Python BP)

I'll post a patch going this way later today

> (I had been laboring under the misconception that a finish breakpoint
> took a linespec and then did the bookkeeping of "note function entry /
> set a new breakpoint" -- but actually I like your simpler approach
> better, and the latter can be done more easily purely in Python.)

I'm not sure to understand exactly what you had in mind, but if you
prefer my solution that's okay


Thanks,

Kevin