This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Additional testsuite alternative


Daniel,

I don't think something like this would be of general use. The .exp files have the full power of a script language and nothing can beat that. Compiler tests are pretty much different from debugger tests, because debuggers are interactive beasts.

But as a special harness to drive C++ tests I think it is a good idea. The majority of tests deal with checking for some formatted output of a C++ construct and maybe the full power of scripting is not needed. Maybe it can even be adapted to other languages where what is being tested is of similar nature. There is a precedent already in that the gdbtk tests use their own spec files (.test).

Anyway, I suggest that you do not try and make it too general, but just something that is capable of simplifying these types of C++ tests. Use .exp for the non-trivial tests.

One more question: You still need a minimum .exp file, I believe, which is what runtest will find and try to run. It is also part of what identify tests in the results and so one.

Regards,
Fernando


Daniel Jacobowitz wrote:
Does anyone have any reaction to this?  Fernando, how would you feel
about adding the harness for this to the testsuite?

The background is that I'm probably going to change the behaviour (and
definitely going to increase the visibility) of c_print_type, so I want
to have some unit tests written for it first.

On Mon, Sep 16, 2002 at 03:25:46PM -0400, Daniel Jacobowitz wrote:

OK, the files were on a different machine, so this wasn't a couple minutes
after I promised it this morning.  Can't win 'em all.

I very much admire the way GCC's testsuite works.  You don't have to write
code for new tests; you can just drop them in.  Binutils has a two-file
version (GCC's is all one-file, using the DejaGNU "dg" harness) that's
comparable.

GDB testing is more complicated, but I think that for a significant number
of tests we can get the same result.  Some more complex tests will still
want to be their own .exp files, of course.  Here's how what I've
implemented so far looks.

Source file two.cc:
===
struct OneStruct {
 int simple;
};
struct OneStruct StrOne;
const struct OneStruct *ConstStrOnePtr;

int FunctionWithPtrs (const struct OneStruct *one, const int *two)
{
 return 0;
}

int
main ()
{
 return 0;
}
===

Source file two.x:
===
#compile two.cc two.exe executable debug
#runto main
#test "ptype StrOne"
type = class OneStruct {
 public:
   int simple;
[synthetic OneStruct]}
#test "ptype ConstStrOnePtr"
type = const class OneStruct {
 public:
   int simple;
[synthetic OneStruct]} \*
===

Lines starting with "#[a-z]" are commands.  The ones we have so far (since
they were all I needed for the test I was writing at the time :) are:

#compile <source> <binfile> <type> <options>

Works just like a call to gdb_compile, but the source is relative to the
location of the .x file.

#runto <function>

Calls either runto or runto_main depending on the argument.

#test [-const] "command"

Sends "command" to GDB and watches for the response, which is a series of
lines not starting with #.  If -const is specified then consts (volatiles,
etc.) will be left alone; otherwise they are made optional iff the debug
format is stabs.  Later I'll refine it to "iff the debug format is stabs and
the compiler does not produce const type qualifiers in its stabs".

The string [synthetic ClassName] is special and expands to a regex (iff
stabs) that matches the synthesized constructors and assignment operator
that GCC emits when using stabs (simplisticly; it's not meant to be perfect,
just to reduce clutter in testing simple structures, and I haven't thought
of a way to properly prevent the synthesized methods from showing up.  I
think I just did, though, and if it works this construct will die.)


Obviously the syntax isn't complete.  It doesn't support comments yet but
that's easy.  It's not set in stone; I'd kind of like to use something other
than '#' so that I can use '#' for comments.  Maybe '%'?


The general intention is that this makes it easier to write tests, and
drastically easier to read them and figure out what the expected output is.

Thoughts?  Is this interesting to anyone else?

--
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



--
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]