This is the mail archive of the gdb-patches@sourceware.cygnus.com 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]

Re: RFA: permanent breakpoints



> It doesn't look, at the Tcl level, like there is any way I can tell
> these breakpoints are special.  I probably don't want to show them
> to the user at all in the GUI, right?  If I do show them, then I
> certainly don't want to allow the user to think that he/she can
> modify them.

The visibility of a breakpoint should still be determined by b->type,
just as it is now.

Whether a breakpoint is permanent is independent of whether the user
should see it.  For now, we only need a permanent breakpoint to
describe the HP-UX ELF dynamic linker to GDB, but someday we might
have a user interface that allows the user to tell GDB about
breakpoints hard-coded into their program.

Indeed, there's no way for the Tcl code to discover that the
breakpoint is permanent.  I just went for the minimal plausible
interface change, since I don't know what you guys want/need.

At the moment, since the only permanent breakpoints GDB will ever
create have a type of bp_shlib_event, the user should never see them.
When we add a way for the user to declare their own, we should make
corresponding changes to GDBTk.

> Is the only way you know they are special the value of b->enable?  If
> so, then maybe we need to change the Enabled value returned from
> gdb_get_breakpoint_info from a simple boolean to a three valued
> quantity, 0 being disabled, 1 being enabled, and -1 for permanent.
> Actually, we should also have something for the call_disabled &
> shlib_disabled types as well.  I made them -2.  Then in the GUI, I
> will probably just ignore anything with a negative enabled value.  
> 
> I appended a patch to this message.  Look okay?

I'd like to suggest something even simpler:


Index: gdbtk-cmds.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/gdbtk-cmds.c,v
retrieving revision 2.57
diff -c -c -b -F'^(' -r2.57 gdbtk-cmds.c
*** gdbtk-cmds.c	1999/09/03 10:15:31	2.57
--- gdbtk-cmds.c	1999/09/13 19:57:36
***************
*** 3968,3974 ****
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
  			    Tcl_NewStringObj (bptypes[b->type], -1));
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
! 			    Tcl_NewBooleanObj (b->enable == enabled));
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
  			    Tcl_NewStringObj (bpdisp[b->disposition], -1));
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
--- 3968,3974 ----
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
  			    Tcl_NewStringObj (bptypes[b->type], -1));
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
! 			    Tcl_NewBooleanObj (b->enable != disabled));
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,
  			    Tcl_NewStringObj (bpdisp[b->disposition], -1));
    Tcl_ListObjAppendElement (NULL, result_ptr->obj_ptr,


shlib_disabled means, "This breakpoint has been disabled because it's
in a shared library which isn't loaded yet.  I'll re-enable it once
the shared library comes back."  Are you sure the user cares about
this?  I'd just display it as an enabled breakpoint --- it's only
disabled while it couldn't possibly be hit, and will be enabled as
soon as it's possible to hit it again, so the user can't tell the
difference between it and an enabled breakpoint.

call_disabled I don't understand, but I think it's a transient state
which will go away as soon as the inferior stops.  Again, I'm not sure
the user cares about this distinction.  It's enabled as far as she's
concerned.

permanent, is indeed a distinction the user cares about.  But there's
a lot of other user interface stuff which needs to go on before
they're ever visible.  We can think about the CL interface and the
Insight interface together.

In short, only the value `disabled' actually means that the breakpoint
is disabled, from the user's point of view.

So actually, I guess permanent breakpoints will become relevant to
Insight at the same time they become relevant to the CLI.  We can do
the interface work then.  No real changes are needed now.

What do you think?

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