* Re: Pascal extensions for GDB
1999-10-25 15:47 ` Pascal extensions for GDB Stan Shebs
@ 1999-10-25 16:18 ` Mark Kettenis
0 siblings, 0 replies; 2+ messages in thread
From: Mark Kettenis @ 1999-10-25 16:18 UTC (permalink / raw)
To: shebs; +Cc: muller, gdb-patches
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:
^ permalink raw reply [flat|nested] 2+ messages in thread