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] Make enable reset disposition


On Thu, Jan 26, 2012 at 4:23 PM, Stan Shebs <stanshebs@earthlink.net> wrote:
> In the process of developing an additional enablement option (to be posted
> soon), I ran across this little bit of behavior that seems wrong; if you do
> "enable once" and then "enable" on a breakpoint, the disposition is
> unchanged - the breakpoint is still going to get disabled after being hit.
> ?(Similarly for "enable delete" breakpoints.)
>
> While one could argue that this is good, because you can toggle a
> breakpoint's enablement independently of its ultimate disposition, the
> downside is that you're stuck with your original choice; once you've set a
> breakpoint's disposition to delete for instance, there is no way to undo
> that, and when the breakpoint is hit, it's gone, conditions and command list
> and all.
>
> Having "enable" reset dispositions has its own fault, namely that if you do
> just "enable" to enable all breakpoints, and they have different
> dispositions, then all the dispositions are reset en masse, and you would
> have to manually do a combination of "enable once", "enable delete", etc to
> get those back to desired values.
>
> A more complicated solution might be to introduce an additional flavor or
> option of enable command ("enable always"?), but I wouldn't like to try to
> explain the different flavors to users, and chances are that nobody would
> remember it anyway.

Hi.
I don't know that I would call it *more* complicated.
IIUC, there two independent(/orthogonal) attributes of a breakpoint
(once vs delete vs always, and enabled vs disabled) and they are
controlled by the same command.
Oops.

From a u/i perspective keeping the orthogonality feels right.
Also, having "enable" reset dispositions en masse does bother me.
Does this affect tbreak-created breakpoints?

It feels like adding "always" doesn't muddy the waters any more than
they already are. :-)
If one were do do this again, having a new command instead of "enable"
may be easier for user's to digest and remember.


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