This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[MI] --thread-group test (was: RE: [MI] Duplicate --thread-group flag not detected)
> > 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