From: Daniel Jacobowitz <drow@mvista.com>
To: Fernando Nasser <fnasser@redhat.com>, gdb-patches@sources.redhat.com
Subject: [RFA/testsuite]: Stop dbx.exp insanity
Date: Sat, 30 Mar 2002 11:32:00 -0000 [thread overview]
Message-ID: <20020330143231.A25949@nevyn.them.org> (raw)
There were two issues with dbx.exp which could cause hard-to-identify
testsuite failures:
- It reimplemented gdb_file_cmd and left it changed. This means that the
behavior of tests varied based on whether they ran before or after
dbx.exp.
- The reimplemented gdb_file_cmd was buggy in and of itself.
The attached patch has been verified to fix both things. I restore the old
gdb_file_cmd after dbx.exp is done; and for kicks I ran the testsuite
without the line that restores it and verified that the other bugs were
gone. The problem was forgetting to call exec-file in some cases.
Fernando, is this OK to commit?
Two examples in particular. This is the one inexplicable failure caused by
my stabs line-numbering patch:
Running ../../../src/gdb/testsuite/gdb.base/dbx.exp ...
Running ../../../src/gdb/testsuite/gdb.base/reread.exp ...
FAIL: gdb.base/reread.exp: second pass: breakpoint foo in first file
# of unexpected failures 1
vs.
Running ../../../src/gdb/testsuite/gdb.base/reread.exp ...
(no failures)
Here's one in dump.exp:
Running ../../../src/gdb/testsuite/gdb.base/dbx.exp ...
Running ../../../src/gdb/testsuite/gdb.base/dump.exp ...
FAIL: gdb.base/dump.exp: reload array as value, srec
FAIL: gdb.base/dump.exp: reload struct as value, srec
FAIL: gdb.base/dump.exp: reload array as memory, srec
FAIL: gdb.base/dump.exp: reload struct as memory, srec
FAIL: gdb.base/dump.exp: reload array as value, intel hex
FAIL: gdb.base/dump.exp: reload struct as value, intel hex
FAIL: gdb.base/dump.exp: reload array as memory, intel hex
FAIL: gdb.base/dump.exp: reload struct as memory, intel hex
FAIL: gdb.base/dump.exp: reload array as value, tekhex
FAIL: gdb.base/dump.exp: reload struct as value, tekhex
FAIL: gdb.base/dump.exp: reload array as memory, tekhex
FAIL: gdb.base/dump.exp: reload struct as memory, tekhex
vs.
Running ../../../src/gdb/testsuite/gdb.base/dump.exp ...
(no failures)
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
2002-03-30 Daniel Jacobowitz <drow@mvista.com>
* gdb.base/dbx.exp: Restore old definition of gdb_file_cmd
when finished. Make gdb_file_cmd send "exec-file" when
appropriate.
Index: dbx.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/dbx.exp,v
retrieving revision 1.3
diff -u -r1.3 dbx.exp
--- dbx.exp 2001/05/23 19:04:13 1.3
+++ dbx.exp 2002/03/30 19:27:00
@@ -168,6 +168,11 @@
# file into gdb for a dbx session. So why not just override gdb_file_cmd with the
# right sequence of events, allowing gdb_load to do its normal thing? This way
# remotes and simulators will work, too.
+#
+# [drow 2002-03-30]: We can restore the old gdb_file_cmd afterwards, though.
+set old_gdb_file_cmd_args [info args gdb_file_cmd]
+set old_gdb_file_cmd_body [info body gdb_file_cmd]
+
proc gdb_file_cmd {arg} {
global verbose
global loadpath
@@ -206,6 +211,11 @@
verbose "\t\tLoaded $arg into the $GDB"
send_gdb "exec-file $arg\n"
gdb_expect {
+ -re "A program is being debugged already.*Kill it.*y or n. $" {
+ send_gdb "y\n"
+ verbose "\t\tKilling previous program being debugged"
+ exp_continue
+ }
-re ".*$gdb_prompt $" {
verbose "\t\tLoaded $arg with new symbol table into $GDB"
return 0
@@ -221,23 +231,9 @@
perror "$arg wasn't compiled with \"-g\""
return -1
}
- -re "A program is being debugged already.*Kill it.*y or n. $" {
- send_gdb "y\n"
- verbose "\t\tKilling previous program being debugged"
- exp_continue
- }
-re "Load new symbol table from \".*\".*y or n. $" {
send_gdb "y\n"
- gdb_expect {
- -re "Reading symbols from.*done.*$gdb_prompt $" {
- verbose "\t\tLoaded $arg with new symbol table into $GDB"
- return 0
- }
- timeout {
- perror "(timeout) Couldn't load $arg, other program already loaded."
- return -1
- }
- }
+ exp_continue
}
-re ".*No such file or directory.*$gdb_prompt $" {
perror "($arg) No such file or directory\n"
@@ -339,4 +335,6 @@
gdb_exit
set GDBFLAGS $saved_gdbflags
+eval proc gdb_file_cmd {$old_gdb_file_cmd_args} {$old_gdb_file_cmd_body}
+
return 0
next reply other threads:[~2002-03-30 19:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-30 11:32 Daniel Jacobowitz [this message]
2002-03-30 15:42 ` Fernando Nasser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020330143231.A25949@nevyn.them.org \
--to=drow@mvista.com \
--cc=fnasser@redhat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox