This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
MI testsuite fix
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Date: Thu, 10 Apr 2008 21:02:07 +0100
- Subject: MI testsuite fix
Running the testsuite in linux native async mode in
an x86_64-unknown-linux-gnu with -m32 to simulate an x86-pc-linux-gnu,
I get a bunch of MI testsuite errors related to this difference of
output in async vs sync modes:
async:
220^running
&"warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at
ffffe0b4\n"
(gdb)
sync:
220^running
(gdb)
&"warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at
ffffe0b4\n"
It results in errors that look like these:
220-exec-run
220^running
&"warning: Lowest section in system-supplied DSO at 0xffffe000 is .hash at
ffffe0b4\n"
(gdb)
~"[Thread debugging using libthread_db enabled]\n"
220*stopped,thread-id="1",frame={addr="0x08048542",func="main",args=[],file="../../../src/gdb/testsuite/gdb.mi/pth
reads.c",fullname="/home/pedro/gdb/track_mi/src/gdb/testsuite/gdb.mi/pthreads.c",line="79"}
(gdb)
ERROR: Unable to start target
The difference comes from the fact that on sync mode, the MI prompt is output
immediatelly after ^running, while on async mode, it is output a bit later.
if (!target_can_async_p ())
{
/* NOTE: For synchronous targets asynchronous behavour is faked by
printing out the GDB prompt before we even try to execute the
command. */
if (last_async_command)
fputs_unfiltered (last_async_command, raw_stdout);
fputs_unfiltered ("^running\n", raw_stdout);
fputs_unfiltered ("(gdb) \n", raw_stdout);
gdb_flush (raw_stdout);
}
else
{
/* FIXME: cagney/1999-11-29: Printing this message before
calling execute_command is wrong. It should only be printed
once gdb has confirmed that it really has managed to send a
run command to the target. */
if (last_async_command)
fputs_unfiltered (last_async_command, raw_stdout);
fputs_unfiltered ("^running\n", raw_stdout);
}
The async case looks more correct than the sync one, so I propose fixing
the regex to match warnings before the MI prompt.
It is also arguable if that warning has any value, but in any case,
we should be filtering warnings.
Fixing this leaves me with one MI regression, mi-pending.exp, which is
related to throwing an exception running the exec cleanups, which deletes
the MI token, when it shouldn't. That is fixed by Vladimir's pending
"murder exec cleanup" patch, or when the token in *stopped is removed.
Both will go in very soon.
--
Pedro Alves
2008-04-10 Pedro Alves <pedro@codesourcery.com>
* lib/mi-support.exp (mi_warnings): New.
(mi_run_cmd): Filter warnings in the -exec-run case.
---
gdb/testsuite/lib/mi-support.exp | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: src/gdb/testsuite/lib/mi-support.exp
===================================================================
--- src.orig/gdb/testsuite/lib/mi-support.exp 2008-04-10 20:45:40.000000000 +0100
+++ src/gdb/testsuite/lib/mi-support.exp 2008-04-10 20:51:46.000000000 +0100
@@ -33,6 +33,8 @@ global mi_inferior_tty_name
set MIFLAGS "-i=mi"
+set mi_warnings "(&\".*\"\r\n)*"
+
#
# mi_gdb_exit -- exit the GDB, killing the target program if necessary
#
@@ -780,6 +782,7 @@ proc mi_run_cmd {args} {
return -1
}
global mi_gdb_prompt
+ global mi_warnings
if [target_info exists gdb_init_command] {
send_gdb "[target_info gdb_init_command]\n";
@@ -821,7 +824,7 @@ proc mi_run_cmd {args} {
send_gdb "220-exec-run $args\n"
gdb_expect {
- -re "220\\^running\r\n${mi_gdb_prompt}" {
+ -re "220\\^running\r\n${mi_warnings}${mi_gdb_prompt}" {
}
timeout {
perror "Unable to start target"