This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] breakpoint.c: don't generate bp events for internal bps
- To: keiths at cygnus dot com
- Subject: Re: [RFA] breakpoint.c: don't generate bp events for internal bps
- From: "Eli Zaretskii" <eliz at is dot elta dot co dot il>
- Date: Fri, 11 May 2001 19:56:50 +0300
- CC: fnasser at redhat dot com, gdb-patches at sources dot redhat dot com
- References: <Pine.GSO.4.33.0105110805480.27065-100000@ryobi.cygnus.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> Date: Fri, 11 May 2001 08:13:49 -0700 (PDT)
> From: Keith Seitz <keiths@cygnus.com>
>
> breakpoint_delete_event, breakpoint_create_event, and
> breakpoint_modify_event are defined in gdb-events.[ch],sh. They are, as
> the comments from the files explain, for user interface events.
>
> Well, it is my contention that user interfaces need not (indeed, should
> not) know anything about bp_none, bp_until, bp_finish, bp_longjmp,
> bp_longjmp_resume, bp_step_resume, bp_through_sigtramp,
> bp_watchpoint_scope, bp_call_dummy, bp_shlibevent, bp_thread_event,
> bp_catch_unload, bp_catch_fork, bp_catch_vfork, bp_catch_exec,
> bp_catch_catch, and bp_catch_throw breakpoint events (or some major subset
> of these). What libgdb does for its own housekeeping is its business, and
> its business alone. Breakpoints of these types are PRIVATE to gdb.
So you are saying that the UI will never need to support the
maintenance commands which expose those internal events to the user?
I'm not experienced enough with GDB UIs, so I cannot judge whether
this is true, but won't someone want the maintenance commands?
> (I suspect this isn't helping too much, is it?)
Well, at least I understand what do you mean now ;-)