This is the mail archive of the gdb-patches@sourceware.org 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: [patch] Add an evaluation function hook to Python breakpoints.


Doug Evans <dje@google.com> writes:

>> It's nothing more than a hook for the user to accomplish some truth
>> finding mission at breakpoint evaluation time. ÂIf the user wants to
>> collect data, then I think they can do that -- that is we should not
>> attempt to stop them. ÂI probably worded my email hastily; FWIW I think
>> this a place where we can write conditional breakpoints that can be
>> written entirely in Python.
>
> I'm not suggesting we stop users from doing quick hacks. :-)
> [Heck, can they already write a breakpoint condition in Python?  E.g.
> with a python convenience function?]

We could call the function "collect" (or whatever we want) and allow the
user to collect data and document it/bless it as a way to do it.  And if
on that data they wanted to issue a stop, they could return True.  We
could remove any mention of it being a replacement for conditional
breakpoints. If that satisfies your requirements, then it is simply a name
change/messaging/documentation tweak.  

If this is just to be a pure data collecting hook, I suspect we would
have to move the code up from bpstat_check_breakpoint_conditions to the
calling function bpstop_stop_status. Then we would not be able to give
the user the functionality to stop.  But it would be the same code in a
different place

I like the first option, and there is no performance loss for
providing the option to stop.

What do you think?

Cheers,
Phil


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