From: Fernando Nasser <fnasser@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/testsuite]: Stop dbx.exp insanity
Date: Sat, 30 Mar 2002 15:42:00 -0000 [thread overview]
Message-ID: <3CA64CD5.8DB70D78@redhat.com> (raw)
In-Reply-To: <20020330143231.A25949@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> 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?
>
Cool! Yes, thank you.
Fernando
> 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
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9
prev parent reply other threads:[~2002-03-30 23:42 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-30 11:32 Daniel Jacobowitz
2002-03-30 15:42 ` Fernando Nasser [this message]
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=3CA64CD5.8DB70D78@redhat.com \
--to=fnasser@redhat.com \
--cc=drow@mvista.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