Re: Pascal extensions for GDB

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Mon, 25 Oct 1999 15:47:10 -0700
   From: Stan Shebs <shebs@cygnus.com>

	PS :
	 FPC supports long double in 10 bytes instead of 12 like in C !
      Is that supported with your current FPU patches ??

Argh.  (I didn't notice this PS at the first time your message passed
my eye.)  Are you sure they are really 10 bytes and not 10 bytes plus
2 bytes of garbadge.  AFAIK the i386 has alignment restrictions that
demand that extended precision floating point numbers are aligned on
4-byte boundaries.  That's the reason why sizeof (long double) is a
multiple of 4, i.e. 12 bytes.

   Not having seen the patches, I can't say for sure - it depends on
   how the compiler records info about long doubles, among other things.

If there really are only 10 bytes it makes things difficult.  GDB only
knows about three different floating point types, equivalent with
`float', `double' and `long double', and cannot handle floating point
types whose size differs from the size of one of those types.

Mark
From muller@cerbere.u-strasbg.fr Tue Oct 26 02:06:00 1999
From: Pierre Muller <muller@cerbere.u-strasbg.fr>
To: Stan Shebs <shebs@cygnus.com>
Cc: core@freepascal.org, gdb-patches@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: Pascal extensions for GDB
Date: Tue, 26 Oct 1999 02:06:00 -0000
Message-id: <199910260919.LAA20421@cerbere.u-strasbg.fr>
References: <199910220758.JAA04940@cerbere.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00097.html
Content-length: 776

At 15:47 25/10/99 -0700, you wrote:
>     I would like to submit a big patch for GDB adding
>   support for pascal language !
>
>This is very exciting!  I've long wanted to see a Pascal frontend
>for GDB.
>
>     This patch is approx 750k long 
>   so I do not send it directly now !

  When I wrote this I found this value quite incredible and 
after some work to remove several unimportant files
our diffs reduce now to about 155k !!

  You can find this by anonymous login at
   idefix.wisa.be
under
   /pub/gdbpas
Please first get Readme.txt 
and after pascal.dif file
(both are ascii files)





Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99
From jimb@cygnus.com Tue Oct 26 09:08:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Pierre Muller <muller@cerbere.u-strasbg.fr>
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: Pascal extensions for GDB
Date: Tue, 26 Oct 1999 09:08:00 -0000
Message-id: <npzox6m7h9.fsf@zwingli.cygnus.com>
References: <shebs@cygnus.com> <199910211743.KAA08509@andros.cygnus.com> <199910220758.JAA04940@cerbere.u-strasbg.fr>
X-SW-Source: 1999-q4/msg00098.html
Content-length: 878

>   I would like to submit a big patch for GDB adding
> support for pascal language !

As Stan says: Wonderful!

> PS : FPC supports long double in 10 bytes instead of 12 like in C !
> Is that supported with your current FPU patches ??

At the moment, GDB doesn't have any support for a 10-byte long double
type.  Our long doubles are twelve bytes long, since that's how the C
compilers lay them out.

One could certainly add support to GDB for this.  If your compiler
emits debugging information in a helpful way, it could be reasonably
clean.

However, I think you might want to consider changing your compiler to
use 12-byte long doubles, aligned on a four-byte boundary.  This would
make it easier for Pascal and C code to share data.  Also, the Intel
x86 processor manual says that aligning objects improves performance;
this is why the C ABI requires four-byte alignment.
From grante@visi.com Tue Oct 26 09:58:00 1999
From: Grant Edwards <grante@visi.com>
To: gdb-patches@sourceware.cygnus.com
Subject: RDI patches for gdb 4.18
Date: Tue, 26 Oct 1999 09:58:00 -0000
Message-id: <19991026115814.A24641@visi.com>
X-SW-Source: 1999-q4/msg00099.html
Content-length: 3937

Attached is a patch file generated agains gdb-4.18.  It implements the
changes listed below for rdi target support.

RDI Background (people who don't know what the rdi target is probably
don't care about the patches, but in case somebody is curious...)

The rdi target is used for remotely debugging ARM targets that
implement the Angel Debugging Protocol (ADP).  ADP is generally
implemented in one of two ways:

 1) By running the Angel Monitor (usually in ROM) on the target and
    talking to it via serial port.  AFAICT, this is quite similar to
    putting GDB stubs on the target.

    I don't have a target that runs the Angel monitor, so I haven't
    tested with this type of target.

 2) By buying an ARM processor with a JTAG debugging interface and
    using a JTAG interface box that implements ADP.  The processor
    that is most commonly used this way is the ARM7TDMI.  

    The two JTAG interfaces with which I have tested are the ARM
    Embedded-ICE and the EPI Jeeni.

Still on the todo list: incoporate changes received from Thomas Zenker
that

 + allow the user to get gdb's attention while it's waiting for an 
   ADP packet.

 + clean up some BSD 4.4 issues

 + clean up the code that opens serial ports (the existing code
   tries to outsmart the user regarding serial port names).

The attached patch should work cleanly if applied in the gdb-4.18 main
directory with the command

    $ patch -E -p4 <gdbrdi.patch



----------------------------------------------------------------------
			       Changes
----------------------------------------------------------------------

 * Added the boolean set/show variable rdiheartbeat.  

   This enables or disables ADP link-check "heartbeat" packets sent by
   the host to the target.  Heartbeat packets can cause both the ARM
   Embedded-ICE and the EPI Jeeni to malfunction: If a heartbeat
   packet is received by the target while it is sending a packet, that
   packet will be aborted, and the ADP protocol engine then gets very
   confused.

   Default state is off -- used to hardwired on.


 * Added the boolean set/show variable rdiromatzero.

   Should be set to true if the target has ROM at address 0.  If true,
   then gdb will not tell the target to trap fetches to interrupt
   vectors (which are located at address 0).  Using the Angel monitor,
   attempting to set breakpoints in ROM is an error.  Using JTAG
   debugging of the ARM7TDMI, attempting to set more than two
   breakpoints in ROM is an error.

   Default state is false (vectors will be trapped) -- used to be
   hardwired false.


 * Added command rdilogenable

   Allows the user to log ADP packets that are exchanged between
   gdb and the target.  Both the raw packets are shown and some
   minimal decoding is attempted.  [new feature]

   Default state is disabled.


 * Added command rdilogfile

   Allows the user to specify the filename to which the ADP packet log
   is to be written.  [new feature]

   Default state is "rdi.log".


 * Changed default names for Linux serial ports from /dev/cuan to
   /dev/ttySn.


 * Added code to split the arguments to the 'target rdi' command at the
   first space.  The first word is passed to Adp_OpenDevice as the
   device name, the tail is passed as the "arguments" parameter.  This
   allows user specified baud rates -- among other things that still
   need to be documented [e.g. (gdb) target rdi /dev/ttyS1 19200].

   NB: With very limited testing, the ARM Embedded-ICE seems to run at
   19.2K (though it is reported to be unreliable above 9600), and the
   EPI Jeeni seems to run at 38.4K.


 * Renamed the file rdi-share/endian.h to rdi-share/anendian.h to prevent
   shadowing of /usr/include/endian.h.  This was causing the wrong
   byte order to be used by htons() in the RDI Ethernet driver.

26 October 1999

Grant Edwards,
Comtrol Corporation

----------------------------------------------------------------------
From tromey@cygnus.com Wed Oct 27 13:17:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: gdb-patches@sourceware.cygnus.com 
Subject: profiling gdb
Date: Wed, 27 Oct 1999 13:17:00 -0000
Message-id: <87zox4k129.fsf@cygnus.com>
X-SW-Source: 1999-q4/msg00100.html
Content-length: 2815

Lately I've had occasion to profile parts of gdb.  I wrote the
appended patch, which adds a command to let me enable and disable
profiling.  That way I can profile parts of gdb without getting
misleading data about things I don't care about.

This patch isn't really complete.  At the very least it needs a
configure option to define ENABLE_PROFILE.  I'm posting it to get
feedback.  If this isn't worthwhile, I'll just keep it as my own
private hack.

1999-10-27  Tom Tromey  <tromey@cygnus.com>

	* maint.c: Include <sys/gmon.h> if profiling support enabled.
	(maint_moncontrol): New function.
	(_initialize_maint_cmds): Add `moncontrol' command if profiling
	support is enabled.
	* main.c: Include <sys/gmon.h> if profiling support enabled.
	(main): Turn off profiling if profiling support is enabled.

Tom

Index: main.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/main.c,v
retrieving revision 1.164.2.1
diff -u -r1.164.2.1 main.c
--- main.c	1999/04/15 22:53:48	1.164.2.1
+++ main.c	1999/10/27 19:02:50
@@ -35,6 +35,10 @@
 
 #include "gdb_string.h"
 
+#ifdef ENABLE_PROFILE
+#include <sys/gmon.h>
+#endif
+
 /* Temporary variable for SET_TOP_LEVEL.  */
 
 static int top_level_val;
@@ -127,6 +131,10 @@
   long time_at_startup = get_run_time ();
 
   int gdb_file_size;
+
+#ifdef ENABLE_PROFILE
+  moncontrol (GMON_PROF_OFF);
+#endif
 
   START_PROGRESS (argv[0], 0);
 
Index: maint.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gdb/maint.c,v
retrieving revision 2.27
diff -u -r2.27 maint.c
--- maint.c	1999/04/02 23:11:57	2.27
+++ maint.c	1999/10/27 19:02:53
@@ -38,6 +38,10 @@
 #include <unistd.h>
 #endif
 
+#ifdef ENABLE_PROFILE
+#include <sys/gmon.h>
+#endif
+
 static void maintenance_command PARAMS ((char *, int));
 
 static void maintenance_dump_me PARAMS ((char *, int));
@@ -339,6 +343,24 @@
   return;
 }
 
+#ifdef ENABLE_PROFILE
+/* "maintenance moncontrol <on|off>"  */
+static void
+maint_moncontrol (char *arg, int from_tty)
+{
+  int val;
+  if (arg == NULL || ! *arg)
+    error ("requires argument");
+  if (! strcmp (arg, "on"))
+    val = GMON_PROF_ON;
+  else if (! strcmp (arg, "off"))
+    val = GMON_PROF_OFF;
+  else
+    error ("unrecognized argument");
+  moncontrol (val);
+}
+#endif
+
 void
 _initialize_maint_cmds ()
 {
@@ -431,6 +453,12 @@
   add_cmd ("translate-address", class_maintenance, maintenance_translate_address,
 	   "Translate a section name and address to a symbol.",
 	   &maintenancelist);
+
+#ifdef ENABLE_PROFILE
+  add_cmd ("moncontrol", class_maintenance, maint_moncontrol,
+	   "Enable or disable profiling.",
+	   &maintenancelist);
+#endif
 
   add_show_from_set (
     add_set_cmd ("watchdog", class_maintenance, var_zinteger, (char *)&watchdog,
From hjl@valinux.com Wed Oct 27 13:43:00 1999
From: hjl@valinux.com (H.J. Lu)
To: gdb-patches@sourceware.cygnus.com
Cc: slouken@devolution.com, gdb@sourceware.cygnus.com (GDB)
Subject: A patch for shared library support
Date: Wed, 27 Oct 1999 13:43:00 -0000
Message-id: <19991027204300.7816E3FC1@valinux.com>
X-SW-Source: 1999-q4/msg00101.html
Content-length: 3401

Hi,

I finally get annoyed enough to port Sam's patch to gdb 4.18 in CVS.
When you set a break point in shared library, gdb will crash when you
restart the program. This patch seems to work for me.


-- 
H.J. Lu (hjl@gnu.org)
--
Wed Mar 17 19:49:22 1999  Sam Lantinga (slouken@devolution.com)

	Added function check_solib_consistency() to reload list of
	shared objects when they are added or deleted. This fixed
	crashing when the program being debugged unloaded a dynamic
	library and added a new library afterwards.

	* solib.h (CHECK_SOLIB_CONSISTENCY): New.
	(check_solib_consistency): New prototype.

	* solib.c (check_solib_consistency): Defined.

	* infrun.c (handle_inferior_event): Before calling SOLIB_ADD (),
	call CHECK_SOLIB_CONSISTENCY () if defined.

Index: solib.h
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.h,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 solib.h
--- solib.h	1999/09/09 00:38:38	1.1.1.1
+++ solib.h	1999/10/27 20:35:54
@@ -186,6 +186,11 @@ solib_create_inferior_hook PARAMS ((void
 extern char *
   solib_address PARAMS ((CORE_ADDR));	/* solib.c */
 
+/* Check shared library consistency */
+
+#define CHECK_SOLIB_CONSISTENCY()	check_solib_consistency()
+extern void check_solib_consistency PARAMS ((void));
+
 /* If ADDR lies in a shared library, return its name.  */
 
 #define PC_SOLIB(addr)	solib_address (addr)
Index: solib.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/solib.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 solib.c
--- solib.c	1999/10/19 16:16:27	1.1.1.2
+++ solib.c	1999/10/27 20:29:03
@@ -950,6 +954,38 @@ open_symbol_file_object (arg)
   return 1;
 }
 #endif /* SVR4_SHARED_LIBS */
+
+/*
+  
+GLOBAL FUNCTION
+
+	check_solib_consistency -- check solib list consistency
+
+SYNOPSIS
+
+	void check_solib_consistency (void)
+
+DESCRIPTION
+
+	This module is called whenever we hit a dynamic linker breakpoint
+	and allows us to check the consistency of our shared object list.
+	Without this, dynamic unlinking of objects could crash us.
+ */
+
+void
+check_solib_consistency (void)
+{
+#ifdef SVR4_SHARED_LIBS
+
+  if ( debug_base ) {
+    read_memory (debug_base, (char *) &debug_copy, sizeof (struct r_debug));
+    /* If the shared object state is consistent, we can reload our list */
+    if ( debug_copy.r_state == RT_CONSISTENT )
+      clear_solib();
+  }
+
+#endif	/* SVR4_SHARED_LIBS */
+}
 
 /*
 
Index: infrun.c
===================================================================
RCS file: /work/cvs/gnu/gdb/gdb/infrun.c,v
retrieving revision 1.1.1.2
diff -u -p -r1.1.1.2 infrun.c
--- infrun.c	1999/10/19 16:16:22	1.1.1.2
+++ infrun.c	1999/10/27 20:30:20
@@ -1479,6 +1479,9 @@ handle_inferior_event (struct execution_
 		/* Switch terminal for any messages produced by
 		   breakpoint_re_set.  */
 		target_terminal_ours_for_output ();
+#ifdef CHECK_SOLIB_CONSISTENCY
+		CHECK_SOLIB_CONSISTENCY();
+#endif
 		SOLIB_ADD (NULL, 0, NULL);
 		target_terminal_inferior ();
 	      }
@@ -2409,6 +2412,9 @@ handle_inferior_event (struct execution_
 		/* Switch terminal for any messages produced by
 		   breakpoint_re_set.  */
 		target_terminal_ours_for_output ();
+#ifdef CHECK_SOLIB_CONSISTENCY
+		CHECK_SOLIB_CONSISTENCY();
+#endif
 		SOLIB_ADD (NULL, 0, NULL);
 		target_terminal_inferior ();
 	      }
From jtc@redback.com Wed Oct 27 13:44:00 1999
From: jtc@redback.com (J.T. Conklin)
To: tromey@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: profiling gdb
Date: Wed, 27 Oct 1999 13:44:00 -0000
Message-id: <5mpuy0cz5q.fsf@jtc.redbacknetworks.com>
References: <87zox4k129.fsf@cygnus.com>
X-SW-Source: 1999-q4/msg00102.html
Content-length: 969

>>>>> "Tom" == Tom Tromey <tromey@cygnus.com> writes:
Tom> Lately I've had occasion to profile parts of gdb.  I wrote the
Tom> appended patch, which adds a command to let me enable and disable
Tom> profiling.  That way I can profile parts of gdb without getting
Tom> misleading data about things I don't care about.

I did pretty much the same thing when I was trying to determine why
some my user defined functions were so slow.  

Tom> This patch isn't really complete.  At the very least it needs a
Tom> configure option to define ENABLE_PROFILE.  I'm posting it to get
Tom> feedback.  If this isn't worthwhile, I'll just keep it as my own
Tom> private hack.

At the very least, if this gets integrated there will be no need for
anyone else to (re-)implement it.

You include <sys/gmon.h>, perhaps for a moncontrol() declaration.  But
not all systems have that header, and those who do may not declare
moncontrol().

        --jtc

-- 
J.T. Conklin
RedBack Networks
From tromey@cygnus.com Wed Oct 27 13:46:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: jtc@redback.com
Cc: tromey@cygnus.com, gdb-patches@sourceware.cygnus.com
Subject: Re: profiling gdb
Date: Wed, 27 Oct 1999 13:46:00 -0000
Message-id: <199910272046.NAA04659@ferrule.cygnus.com.>
References: <87zox4k129.fsf@cygnus.com> <5mpuy0cz5q.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q4/msg00103.html
Content-length: 344

>>>>> "JT" == J T Conklin <jtc@redback.com> writes:

JT> You include <sys/gmon.h>, perhaps for a moncontrol() declaration.
JT> But not all systems have that header, and those who do may not
JT> declare moncontrol().

The patch has other bugs.  I'll fix the conf stuff and those bugs and
resubmit "soon", unless I get discouraging responses.

T
From guo@cup.hp.com Thu Oct 28 17:06:00 1999
From: Jimmy Guo <guo@cup.hp.com>
To: gdb-patches@sourceware.cygnus.com
Subject: (patch) hpjyg01: GDB breakpoint ignore count annoation
Date: Thu, 28 Oct 1999 17:06:00 -0000
Message-id: <Pine.LNX.4.10.9910281701070.10501-100000@hpcll168.cup.hp.com>
References: <Pine.LNX.4.10.9907221847020.2057-100000@hpcll168.cup.hp.com>
X-SW-Source: 1999-q4/msg00104.html
Content-length: 5913

Here is a patch, against GDB 19991025 snapshot, to provide breakpoint
ignore count annotation, needed by debugger GUI relying on gdb
annotations, and the related test change to gdb.base/annota1.exp.

Tentatively named 'hpjyg01' as I have other patches coming which might
require sequencing.

- Jimmy Guo, guo@cup.hp.com

Index: gdb/ChangeLog
/opt/gnu/bin/diff -r -c -N -L gdb/ChangeLog gdb/ChangeLog@@/GDB_1999_10_25 gdb/ChangeLog
*** gdb/ChangeLog
--- gdb/ChangeLog	Thu Oct 28 16:55:28 1999
***************
*** 1,3 ****
--- 1,13 ----
+ 1999-10-28	Jimmy Guo	<guo@cup.hp.com>
+ 
+ 	* annotate.c (breakpoints_changed,flag_ignore_count,
+ 	annotate_stopped): Provide annotation for breakpoint
+ 	ignore_count changes but only provide once at annotate_stopped
+ 	time for sucessive ignore_count triggered breakpoint changes, to
+ 	make the GUI happy yet lazy.
+ 	* breakpoint.c (bpstat_stop_status): call flag_ignore_count to
+ 	inform ignore_count change.
+ 
  Mon Oct 25 18:22:06 1999  Andrew Cagney  <cagney@b1.cygnus.com>
  
  	* remote.c: Document future of compare_sections_command.
Index: gdb/annotate.c
/opt/gnu/bin/diff -r -c -N -L gdb/annotate.c gdb/annotate.c@@/GDB_1999_10_25 gdb/annotate.c
*** gdb/annotate.c
--- gdb/annotate.c	Thu Oct 28 16:46:44 1999
***************
*** 40,45 ****
--- 40,47 ----
  void (*annotate_signal_hook) PARAMS ((void));
  void (*annotate_exited_hook) PARAMS ((void));
  
+ static int ignore_count_changed = 0;
+ 
  static void
  print_value_flags (t)
       struct type *t;
***************
*** 57,65 ****
--- 59,81 ----
      {
        target_terminal_ours ();
        printf_unfiltered ("\n\032\032breakpoints-invalid\n");
+       if (ignore_count_changed)
+ 	ignore_count_changed = 0;	/* Avoid multiple break annotations. */
      }
  }
  
+ /* The GUI needs to be informed of ignore_count changes, but we don't
+    want to provide successive multiple breakpoints-invalid messages
+    that are all caused by the fact that the ignore count is changing
+    (which could keep the GUI very busy).  One is enough, after the target
+    actually "stops". */
+ void
+ flag_ignore_count_change ()
+ {
+   if (annotation_level > 1)
+     ignore_count_changed = 1;
+ }
+ 
  void
  annotate_breakpoint (num)
       int num;
***************
*** 108,113 ****
--- 124,134 ----
      {
        if (annotation_level > 1)
  	printf_filtered ("\n\032\032stopped\n");
+     }
+   if (annotation_level > 1 && ignore_count_changed)
+     {
+       ignore_count_changed = 0;
+       breakpoints_changed ();
      }
  }
  
Index: gdb/breakpoint.c
/opt/gnu/bin/diff -r -c -N -L gdb/breakpoint.c gdb/breakpoint.c@@/GDB_1999_10_25 gdb/breakpoint.c
*** gdb/breakpoint.c
--- gdb/breakpoint.c	Thu Oct 28 11:58:49 1999
***************
*** 2420,2425 ****
--- 2420,2426 ----
  	else if (b->ignore_count > 0)
  	  {
  	    b->ignore_count--;
+ 	    flag_ignore_count_change ();
  	    bs->stop = 0;
  	  }
  	else
Index: gdb/testsuite/ChangeLog
/opt/gnu/bin/diff -r -c -N -L gdb/testsuite/ChangeLog gdb/testsuite/ChangeLog@@/GDB_1999_10_25 gdb/testsuite/ChangeLog
*** gdb/testsuite/ChangeLog
--- gdb/testsuite/ChangeLog	Thu Oct 28 16:57:38 1999
***************
*** 1,3 ****
--- 1,9 ----
+ 1999-10-28	Jimmy Guo	<guo@cup.hp.com>
+ 
+ 	* gdb.base/annota1.c, gdb.base/annota1.exp: add test to check
+ 	that breakpoint ignore count changes are annotated but only once
+ 	for successive ignore count changes.
+ 
  1999-10-18  Jim Blandy  <jimb@zwingli.cygnus.com>
  
  	* gdb.threads/linux-dp.c, gdb.threads/linux-dp.exp: New test suite
Index: gdb/testsuite/gdb.base/annota1.c
/opt/gnu/bin/diff -r -c -N -L gdb/testsuite/gdb.base/annota1.c gdb/testsuite/gdb.base/annota1.c@@/GDB_1999_10_25 gdb/testsuite/gdb.base/annota1.c
*** gdb/testsuite/gdb.base/annota1.c
--- gdb/testsuite/gdb.base/annota1.c	Thu Oct 28 16:01:53 1999
***************
*** 39,44 ****
--- 39,50 ----
  
    printf ("value is %d\n", value);
    printf ("my_array[2] is %d\n", my_array[2]);
+   
+   {
+     int i;
+     for (i = 0; i < 5; i++)
+       value++;
+   }
  
    return 0;
  }
Index: gdb/testsuite/gdb.base/annota1.exp
/opt/gnu/bin/diff -r -c -N -L gdb/testsuite/gdb.base/annota1.exp gdb/testsuite/gdb.base/annota1.exp@@/GDB_1999_10_25 gdb/testsuite/gdb.base/annota1.exp
*** gdb/testsuite/gdb.base/annota1.exp
--- gdb/testsuite/gdb.base/annota1.exp	Thu Oct 28 16:42:43 1999
***************
*** 359,364 ****
--- 359,412 ----
    timeout { fail "re-run (timeout)" }
  }
  
+ #
+ # Test that breakpoints-invalid is issued once and only once for
+ # breakpoint ignore count changes, after annotation stopped.
+ #
+ send_gdb "break 46\n"
+ gdb_expect {
+     -re "Breakpoint 5 at $hex: file .*$srcfile, line 46.*$gdb_prompt$" {
+ 	pass "break at 46"
+     }
+     -re ".*$gdb_prompt$" { fail "break at 46" }
+     timeout { fail "break at 46 (timeout)" }
+ }
+ 
+ send_gdb "ignore 5 4\n"
+ gdb_expect {
+     -re "Will ignore next 4 crossings of breakpoint 5.*$gdb_prompt$" {
+ 	pass "ignore 5 4"
+     }
+     -re ".*$gdb_prompt$" { fail "ignore 5 4" }
+     timeout { fail "ignore 5 4 (timeout)" }
+ }
+ 
+ send_gdb "continue\n"
+ gdb_expect {
+     -re ".*$srcfile:46:.*\032\032stopped\r\n\r\n\032\032breakpoints-invalid\r\n$gdb_prompt$" {
+ 	pass "annotate ignore count change"
+     }
+     -re ".*$gdb_prompt$" { fail "annotate ignore count change" }
+     timeout { fail "annotate ignore count change (timeout)" }
+ }
+ 
+ # check that ignore command is working, or the above can provide
+ # misleading assurance ...
+ 
+ send_gdb "next\n"
+ gdb_expect {
+     -re "$gdb_prompt$" {}
+     timeout { fail "next to exit loop" }
+ }
+ 
+ send_gdb "next\n"
+ gdb_expect {
+     -re ".*$srcfile:49:.*$gdb_prompt$" {
+ 	pass "breakpoint ignore count"
+     }
+     -re ".*$gdb_prompt$" { fail "breakpoint ignore count" }
+     timeout { fail "breakpoint ignore count (timeout)" }
+ }
  
  #
  # Send a signal that is not handled; test: