[MI] --thread-group test (was: RE: [MI] Duplicate --thread-group flag not detected)

[Marc Khouzam <marc.khouzam@ericsson.com>]

 
> > The problem is that there is another bug that makes the new tests
> > fail, so I had to temporarily comment them out:
> > http://sourceware.org/ml/gdb-patches/2010-11/msg00436.html
> 
> Let's not comment them out, but mark them KFAIL instead, if we can.

Do I need a PR number to use KFAIL?  I don't have one.
I used XFAIL instead.  Is that right?
The annoying part there, is that the tests fails on a timeout,
so marking them XFAIL instead of commenting them out makes
the test file take 10 seconds more...

> > 2010-12-05  Marc Khouzam  <marc.khouzam@ericsson.com>
> > 
> > 	* gdb.mi/mi-general.exp: New file.
> 
> Overal, the test seems fine, but I have limited experimence with
> MI testcases.
> 
> > +set testfile "basics"
> > +set srcfile ${testfile}.c
> > +set binfile ${objdir}/${subdir}/mi-basics
> 
> I believe we decided in the past that it was a bad idea to 
> share the same
> example program between testcases. One reason is that, if we split the
> gdb.mi testcase in multiple groups to allow more parallel testing, we
> might run into troubles.  However, I am just saying that for 
> your info.
> It's not your problem, and I know that you have little time for this
> testcase, and I already appreciate the effort you put into it. So it's
> fine to leave it as is.

To be honest, I don't even need a binary for this test, I can test the 
syntax without actually starting the inferior.  I did this in the patch
below, but I'm not sure if this follows proper 'protocol'.  Just let me
know.

> > +    mi_gdb_test "18-break-insert --thread-group i1 bogus" \
> > +             "18\\^error,msg=\"Function \\\\\"bogus\\\\\" 
> not defined.\"" \
> > +             "Valid --thread-group flag"
> 
> Do we want to test the MI command with a sequence number. I know that
> they are allowed, but aren't they obsolete?

We heavily use them in Eclipse :-)
And I saw that other tests use them, so I thought it would make a
'syntax' test more complete.

Thanks

2010-12-06  Marc Khouzam  <marc.khouzam@ericsson.com>

	* gdb.mi/mi-general.exp: New file.

### Eclipse Workspace Patch 1.0
#P src
Index: gdb/testsuite/gdb.mi/mi-general.exp
===================================================================
RCS file: gdb/testsuite/gdb.mi/mi-general.exp
diff -N gdb/testsuite/gdb.mi/mi-general.exp
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ gdb/testsuite/gdb.mi/mi-general.exp 1 Jan 1970 00:00:00 -0000
@@ -0,0 +1,67 @@
+# Copyright 1999, 2000, 2001, 2002, 2003, 2005, 2007, 2008, 2009, 2010
+# Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+#
+# test general features of Machine interface (MI) operations
+#
+# Verify that, the special MI flags --thread-group, --thread, --frame,
+# --all, --reverse, are parsed properly.
+# The goal is not to test gdb functionality, which is done by other tests,
+# but the command syntax and correct output response to MI operations.
+#
+
+load_lib mi-support.exp
+set MIFLAGS "-i=mi"
+
+gdb_exit
+if [mi_gdb_start separate-inferior-tty] {
+    continue
+}
+
+# No need to actually start the inferior as the tests below only verify MI syntax.
+# What we do instead is see that the parsing works, and passes the MI command
+# further down to GDB, which will then fail because we didn't start the inferior.
+# We wouldn't make it that far if the MI syntax parsing failed
+
+proc test_thread_group_flag {} {
+
+    # If we get to the breakpoint error, it means the -thread-group was parsed properly    
+    mi_gdb_test "18-break-insert --thread-group i1 bogus" \
+             "18\\^error,msg=\"No symbol table is loaded.  Use the \\\\\"file\\\\\" command.\"" \
+             "Valid --thread-group flag"
+
+    # Invalid threadGroupId but it starts with an 'i'.  This is a different code path
+    # than an invalid threadGroupId that does not start with an 'i'.  See below test.
+    mi_gdb_test "21-break-insert --thread-group iX main" \
+             "21\\^error,msg=\"Invalid thread group for the --thread-group option\"" \
+             "Invalid --thread-group flag which starts with an i"
+
+    setup_xfail *-*-*
+    mi_gdb_test "25-break-insert --thread-group XYZ main" \
+             "25\\^error,msg=\"Invalid thread group id\"" \
+             "Invalid --thread-group flag which does not start with an i"
+
+    setup_xfail *-*-*
+    mi_gdb_test "36-break-insert --thread-group i1 --thread-group i2 main" \
+             "36\\^error,msg=\"Duplicate '--thread-group' option\n\"" \
+             "Duplicate --thread-group flag"
+}
+
+
+test_thread_group_flag
+
+mi_gdb_exit
+return 0