Re: MI testsuite fix

Pedro Alves
2008-04-10T21:42:56Z

[-- Attachment #1: Type: text/plain, Size: 2794 bytes --]

A Thursday 10 April 2008 21:02:07, Pedro Alves wrote:
> 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/pthrea
>ds.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.

Ahem, that regex will probably eat to much, cli errors as well. It
isn't because it's called mi_warnings that it will only
filter warnings (blush).

Updated patch attached.

--
Pedro Alves

[-- Attachment #2: mi_fix.diff --]
[-- Type: text/x-diff, Size: 1183 bytes --]

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 22:39:29.000000000 +0100
@@ -33,6 +33,8 @@ global mi_inferior_tty_name

set MIFLAGS "-i=mi"

+set mi_warnings "(&\"warning: .*\"\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"