public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
* [RFA] fix session breakpoints
@ 2001-10-13 11:41 Martin M. Hunt
  2001-12-17 14:49 ` Martin M. Hunt
  0 siblings, 1 reply; 7+ messages in thread
From: Martin M. Hunt @ 2001-10-13 11:41 UTC (permalink / raw)
  To: Insight Mailing List

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" {

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [RFA] fix session breakpoints
  2001-10-13 11:41 [RFA] fix session breakpoints Martin M. Hunt
@ 2001-12-17 14:49 ` Martin M. Hunt
  0 siblings, 0 replies; 7+ messages in thread
From: Martin M. Hunt @ 2001-12-17 14:49 UTC (permalink / raw)
  To: Insight Mailing List

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" {

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFA] fix session breakpoints
  2002-01-02 18:14 ` Keith Seitz
@ 2002-01-03 13:44   ` Martin M. Hunt
  0 siblings, 0 replies; 7+ messages in thread
From: Martin M. Hunt @ 2002-01-03 13:44 UTC (permalink / raw)
  To: Keith Seitz; +Cc: Insight Mailing List

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFA] fix session breakpoints
  2002-01-02 12:42 Martin M. Hunt
  2002-01-02 12:46 ` Tom Tromey
  2002-01-02 12:48 ` Ian Roxborough
@ 2002-01-02 18:14 ` Keith Seitz
  2002-01-03 13:44   ` Martin M. Hunt
  2 siblings, 1 reply; 7+ messages in thread
From: Keith Seitz @ 2002-01-02 18:14 UTC (permalink / raw)
  To: Martin M. Hunt; +Cc: Insight Mailing List

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" {
>

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFA] fix session breakpoints
  2002-01-02 12:42 Martin M. Hunt
  2002-01-02 12:46 ` Tom Tromey
@ 2002-01-02 12:48 ` Ian Roxborough
  2002-01-02 18:14 ` Keith Seitz
  2 siblings, 0 replies; 7+ messages in thread
From: Ian Roxborough @ 2002-01-02 12:48 UTC (permalink / raw)
  To: Martin M. Hunt; +Cc: insight


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" {

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFA] fix session breakpoints
  2002-01-02 12:42 Martin M. Hunt
@ 2002-01-02 12:46 ` Tom Tromey
  2002-01-02 12:48 ` Ian Roxborough
  2002-01-02 18:14 ` Keith Seitz
  2 siblings, 0 replies; 7+ messages in thread
From: Tom Tromey @ 2002-01-02 12:46 UTC (permalink / raw)
  To: Martin M. Hunt; +Cc: Insight Mailing List

>>>>> "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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [RFA] fix session breakpoints
@ 2002-01-02 12:42 Martin M. Hunt
  2002-01-02 12:46 ` Tom Tromey
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Martin M. Hunt @ 2002-01-02 12:42 UTC (permalink / raw)
  To: Insight Mailing List

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" {

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2002-01-03 21:44 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-13 11:41 [RFA] fix session breakpoints Martin M. Hunt
2001-12-17 14:49 ` Martin M. Hunt
2002-01-02 12:42 Martin M. Hunt
2002-01-02 12:46 ` Tom Tromey
2002-01-02 12:48 ` Ian Roxborough
2002-01-02 18:14 ` Keith Seitz
2002-01-03 13:44   ` Martin M. Hunt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).