This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Python Finish Breakpoints

>>>>> "Kevin" == Kevin Pouget <> 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.

[ 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

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.

(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.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]