Re: [RFC/A] testsuite/gdb.c++/ref-types.exp "cleanup"

[Keith Seitz <keiths at cygnus dot com>]

On Fri, 19 Oct 2001, Andrew Cagney wrote:

> There has to be something better.  Look at some of the patters in MI.
> They read ``blah $hex more blah $hex even more blah $hex even more blah
> $hex''.  While all those escape characters are bad I think this
> construct a pattern bit by bit approach is worse.

Unfortunately, there is nothing better that I've found. All the MI tests
use strings and escape all the special characters. We could introduce
something which would concat all the arguments together, but I don't think
this is any more readable.

> Think of it more as making the testsuite contributor friendly.  People
> create test cases by cloning existing code.  People don't create test
> cases by reading the TCL manual.

I don't have a problem making the testsuite more user-friendly. That's
exactly why I have submitted this rfc/a to begin with. I don't buy the
whole "knowing tcl is not a requirement of writing tests" any more than
"knowing C is not a requirement of writing gdb code". Gdb and its
testsuite are equally important parts of a system. You cannot modify
the program "gdb" without knowing C. Likewise, IMO, you cannt write tests
without knowing Tcl. [Let the flames begin.]

I also think that it is a mistake to do cut-n-paste programming, even
(especially?) in the testsuite. <flame>I admit, that as someone who knows
Tcl fairly well, I find dejagnu and our testsuites, ummm, pathetic.
They are all obviously someone's first use of tcl. I know this is
going to upset people, but, well, just look at how they're
written! No one who even uses tcl a little would ever write vararg
procedures for everything. You wouldn't do it in C, you shouldn't
do it in tcl.</flame> Let's face it: the testsuite is a self-propagating
mess.

> Can functions like gdb_expect_list and the like be changed to convert
> their ``string'' into a fixed pattern before passing things on?

Yes, this could be done. We would have to write our own string parser
which would only do variable substitutions. (Actually, with tcl this is
very easy.)

Ok, let me make sure what it is about the testsuite that I find more
contributor-unfriendly than anything else. We say that we don't want to
make people read the tcl manual, but there is an implicit assumption in
the testsuite that presumes that people understand the only undocumented
"feaeture" of tcl: evaluation.

Without looking at the testsuite, which of these are correct? Knowing Tcl
fairly well, I can tell which of these is correct just by looking at them
(most of the time :-). I'll bet very few could figure this out without
looking at the testsuite for guidance.

1. gdb_test "print foo" ".\[0-9\]* = \\(short &\\) @$hex: -1.*$gdb_prompt $"

2. gdb_test "print foo" ".\\[0-\\]* = \\\(short &\\) @$hex: -1.*gdb_prompt $"

3. gdb_test "print foo" ".\[0-9\]* = \\\(short &\\\) @$hex: -1.*$gdb_prompt $"

4. send_gdb {print foo
}
   gdb_expect {
     -re ".\[0-9\]* = \\(short &\\) @$hex: -1.*$gdb_prompt $" { pass }
     ...
   }

5. send_gdb "print foo\n"
   gdb_expect {
     -re ".[0-9]* = \(short &\) @$hex: -1.*$gdb_prompt $" { pass }
     ...
   }

6. send_gdb "print foo\n"
   gdb_expect {
     -re {.[0-9]* = \(short &\) @0x[0-9a-fA-F]+: -1.*(gdb) $} { pass }
     ...
   }

In any case, we're just trading tit-for-tat. Let's face it, our testsuite
requires SOME understanding of tcl and how it works.

So, all of this being said (and maybe I should have just submitted my
additions to the testsuite instead of massaging it), let me summarize what
our options are:

1. Write a new proc (or modify existing ones) so that the pattern argument
would get any variables substituted. Thus we would have:
   gdb_test "print f" {.[0-9]* = $hex" "print f"

This would get changed (by gdb_test or some new proc) to the equivalent
of:
   gdb_test "print f" {.[0-9]* = 0x[0-9a-fA-F]+} "print f"

2. Add new gdb_test_concat procedure which would look like:

   gdb_test_concat "print f" "print value of f" {.[0-9]* = } $hex

   (i.e., proc gdb_test_concat {gdb_cmd test_name args}, args
    concat'ed before being sent to expect)

3. Revert change to "set pattern PAT1; append pattern PAT2" to original
patterns ("PAT1PAT2").

Just let me know what is desired, and I shall embark down that road.
(Maybe I should just submit #3 until something is decided?)

Well, now I have to go into apology mode, because I am undoubtedly
stepping on several feet. I am sorry.

Keith