[RFA] fix session breakpoints

[RFA] fix session breakpoints

[Martin M. Hunt]

I often use Insight to debug itself. After a few hundred times, things get a 
bit slow as Insight sets a few hundred breakpoints on info_command and internal_error.
So here's a simple patch.  It not only stops these breakpoints from accumulating but 
will also eliminate them from .gdbtkinit.

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

2001-12-17  Martin M. Hunt  <hunt@redhat.com>

	* library/session.tcl (SESSION_serialize_bps): Ignore
	breakpoints set on internal_error and info_command because
	these are set by .gdbinit and will be recreated by it.

Index: session.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/session.tcl,v
retrieving revision 1.9
diff -u -r1.9 session.tcl
--- session.tcl	2001/10/28 20:08:39	1.9
+++ session.tcl	2001/12/17 22:43:15
@@ -38,6 +38,13 @@
       address type enabled disposition ignore_count command_list \
       condition thread hit_count user_specification
 
+    # These breakpoints are set when debugging GDB with itself.
+    # Ignore them so they don't accumulate. They get set again
+    # by .gdbinit anyway.
+    if {$function == "internal_error" || $function == "info_command"} {
+      continue
+    }
+    
     switch -glob -- $type {
       "breakpoint" -
       "hw breakpoint" {

[RFA] fix session breakpoints

[Martin M. Hunt]

I often use Insight to debug itself. After a few hundred times, things get a 
bit slow as Insight sets a few hundred breakpoints on info_command and internal_error.
So here's a simple patch.  It not only stops these breakpoints from accumulating but 
will also eliminate them from .gdbtkinit.

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

2001-12-17  Martin M. Hunt  <hunt@redhat.com>

	* library/session.tcl (SESSION_serialize_bps): Ignore
	breakpoints set on internal_error and info_command because
	these are set by .gdbinit and will be recreated by it.

Index: session.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/session.tcl,v
retrieving revision 1.9
diff -u -r1.9 session.tcl
--- session.tcl	2001/10/28 20:08:39	1.9
+++ session.tcl	2001/12/17 22:43:15
@@ -38,6 +38,13 @@
       address type enabled disposition ignore_count command_list \
       condition thread hit_count user_specification
 
+    # These breakpoints are set when debugging GDB with itself.
+    # Ignore them so they don't accumulate. They get set again
+    # by .gdbinit anyway.
+    if {$function == "internal_error" || $function == "info_command"} {
+      continue
+    }
+    
     switch -glob -- $type {
       "breakpoint" -
       "hw breakpoint" {

Re: [RFA] fix session breakpoints

[Martin M. Hunt]

On Monday 17 December 2001 02:47 pm, Martin M. Hunt wrote:
> I often use Insight to debug itself. After a few hundred times, things get
> a bit slow as Insight sets a few hundred breakpoints on info_command and
> internal_error. So here's a simple patch.  It not only stops these
> breakpoints from accumulating but will also eliminate them from .gdbtkinit.

This is a second version of the patch that attempts to check if you are
debugging gdb with itself before ignoring those breakpoints.  It assumes the
name of the executable starts with "gdb" or "insight".  Of course this isn't 
ideal either, but anything else will require GDB changes and IMO will not be 
worth the effort.

-- 
Martin Hunt
GDB Engineer
Red Hat, Inc.

Index: session.tcl
===================================================================
RCS file: /cvs/src/src/gdb/gdbtk/library/session.tcl,v
retrieving revision 1.9
diff -u -r1.9 session.tcl
--- session.tcl	2001/10/28 20:08:39	1.9
+++ session.tcl	2002/01/02 20:35:20
@@ -33,11 +33,28 @@
 proc SESSION_serialize_bps {} {
   set result {}
 
+  set basename [string tolower [file tail $::gdb_exe_name]]
+  if {[string match "gdb*" $basename] 
+      || [string match "insight*" $basename]} {
+    set debugging_gdb 1
+  } else {
+    set debugging_gdb 0
+  }
+  
   foreach bp_num [gdb_get_breakpoint_list] {
     lassign [gdb_get_breakpoint_info $bp_num] file function line_number \
       address type enabled disposition ignore_count command_list \
       condition thread hit_count user_specification
 
+    # These breakpoints are set when debugging GDB with itself.
+    # Ignore them so they don't accumulate. They get set again
+    # by .gdbinit anyway.
+    if {$debugging_gdb} {
+      if {$function == "internal_error" || $function == "info_command"} {
+	continue
+      }
+    }
+    
     switch -glob -- $type {
       "breakpoint" -
       "hw breakpoint" {

Re: [RFA] fix session breakpoints

[Tom Tromey]

>>>>> "Martin" == Martin M Hunt <hunt@redhat.com> writes:

Martin> This is a second version of the patch that attempts to check
Martin> if you are debugging gdb with itself before ignoring those
Martin> breakpoints.  It assumes the name of the executable starts
Martin> with "gdb" or "insight".  Of course this isn't ideal either,
Martin> but anything else will require GDB changes and IMO will not be
Martin> worth the effort.

Won't we run into this problem with any project that sets breakpoints
in .gdbinit?

Could we detect whether any breakpoints are set before setting the
session breakpoints and then avoid saving just those?

Tom

Re: [RFA] fix session breakpoints

[Ian Roxborough]

Hi (happy '02)

Just a thought, but maybe it would be better to assume that the
executable name ends in "insight" or "gdb", so that "i386-elf-gdb"
and others could be detected as well as just "gdb".

Ian.

On Wed, 2 Jan 2002 12:42:10 -0800 "Martin M. Hunt" <hunt@redhat.com> wrote:
>
> On Monday 17 December 2001 02:47 pm, Martin M. Hunt wrote:
> > I often use Insight to debug itself. After a few hundred times, things get
> > a bit slow as Insight sets a few hundred breakpoints on info_command and
> > internal_error. So here's a simple patch.  It not only stops these
> > breakpoints from accumulating but will also eliminate them from .gdbtkinit.
> 
> This is a second version of the patch that attempts to check if you are
> debugging gdb with itself before ignoring those breakpoints.  It assumes the
> name of the executable starts with "gdb" or "insight".  Of course this isn't 
> ideal either, but anything else will require GDB changes and IMO will not be 
> worth the effort.
> 
> -- 
> Martin Hunt
> GDB Engineer
> Red Hat, Inc.
> 
> Index: session.tcl
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtk/library/session.tcl,v
> retrieving revision 1.9
> diff -u -r1.9 session.tcl
> --- session.tcl	2001/10/28 20:08:39	1.9
> +++ session.tcl	2002/01/02 20:35:20
> @@ -33,11 +33,28 @@
>  proc SESSION_serialize_bps {} {
>    set result {}
>  
> +  set basename [string tolower [file tail $::gdb_exe_name]]
> +  if {[string match "gdb*" $basename] 
> +      || [string match "insight*" $basename]} {
> +    set debugging_gdb 1
> +  } else {
> +    set debugging_gdb 0
> +  }
> +  
>    foreach bp_num [gdb_get_breakpoint_list] {
>      lassign [gdb_get_breakpoint_info $bp_num] file function line_number \
>        address type enabled disposition ignore_count command_list \
>        condition thread hit_count user_specification
>  
> +    # These breakpoints are set when debugging GDB with itself.
> +    # Ignore them so they don't accumulate. They get set again
> +    # by .gdbinit anyway.
> +    if {$debugging_gdb} {
> +      if {$function == "internal_error" || $function == "info_command"} {
> +	continue
> +      }
> +    }
> +    
>      switch -glob -- $type {
>        "breakpoint" -
>        "hw breakpoint" {

Re: [RFA] fix session breakpoints

[Keith Seitz]

On Wed, 2 Jan 2002, Martin M. Hunt wrote:

> This is a second version of the patch that attempts to check if you are
> debugging gdb with itself before ignoring those breakpoints.  It assumes the
> name of the executable starts with "gdb" or "insight".  Of course this isn't
> ideal either, but anything else will require GDB changes and IMO will not be
> worth the effort.

While I agree with Tom that it would be nice to fix this for real, I also
acknowledge that there are for more people using sessions to do
init-script like things than those using gdb's init files.

What we really want is something in breakpoint.c to tell us if the
breakpoint was set from an init script. Somehow I doubt we'd get it.

Please add a comment about our failure to deal with this generically, but
for now, we might as well make developers' lives easier. Then commit.

Thanks,
Keith

> Index: session.tcl
> ===================================================================
> RCS file: /cvs/src/src/gdb/gdbtk/library/session.tcl,v
> retrieving revision 1.9
> diff -u -r1.9 session.tcl
> --- session.tcl	2001/10/28 20:08:39	1.9
> +++ session.tcl	2002/01/02 20:35:20
> @@ -33,11 +33,28 @@
>  proc SESSION_serialize_bps {} {
>    set result {}
>
> +  set basename [string tolower [file tail $::gdb_exe_name]]
> +  if {[string match "gdb*" $basename]
> +      || [string match "insight*" $basename]} {
> +    set debugging_gdb 1
> +  } else {
> +    set debugging_gdb 0
> +  }
> +
>    foreach bp_num [gdb_get_breakpoint_list] {
>      lassign [gdb_get_breakpoint_info $bp_num] file function line_number \
>        address type enabled disposition ignore_count command_list \
>        condition thread hit_count user_specification
>
> +    # These breakpoints are set when debugging GDB with itself.
> +    # Ignore them so they don't accumulate. They get set again
> +    # by .gdbinit anyway.
> +    if {$debugging_gdb} {
> +      if {$function == "internal_error" || $function == "info_command"} {
> +	continue
> +      }
> +    }
> +
>      switch -glob -- $type {
>        "breakpoint" -
>        "hw breakpoint" {
>

Re: [RFA] fix session breakpoints

[Martin M. Hunt]

OK, Checked in with a lengthy explanation in the comments and
suggestions about how it could eventually be fixed to deal with
all cases.

Martin

On Wednesday 02 January 2002 06:13 pm, Keith Seitz wrote:
> On Wed, 2 Jan 2002, Martin M. Hunt wrote:
> > This is a second version of the patch that attempts to check if you are
> > debugging gdb with itself before ignoring those breakpoints.  It assumes
> > the name of the executable starts with "gdb" or "insight".  Of course
> > this isn't ideal either, but anything else will require GDB changes and
> > IMO will not be worth the effort.
>
> While I agree with Tom that it would be nice to fix this for real, I also
> acknowledge that there are for more people using sessions to do
> init-script like things than those using gdb's init files.
>
> What we really want is something in breakpoint.c to tell us if the
> breakpoint was set from an init script. Somehow I doubt we'd get it.
>
> Please add a comment about our failure to deal with this generically, but
> for now, we might as well make developers' lives easier. Then commit.
>
> Thanks,
> Keith