Re: [PATCH] Share the "multi_line" helper among all Ada testcases

[Pedro Alves <palves@redhat.com>]

On 03/17/2015 08:08 PM, Joel Brobecker wrote:

> At the time I introduced this function, I thought it should even
> be in gdb.exp, but others did not agree with its usefulness, which
> explains why I ended up duplicating it everywhere.

Do you have a pointer?  I'm curious to see the alternatives
proposed.  If there's something better, I'd argue for instead
converting the Ada tests to use it.

All I found was this though:

 https://sourceware.org/ml/gdb-patches/2008-01/msg00824.html

which didn't sound like an objection, only a pointer to existing
functions that may or not cover your use case.

Note gdb_expect_list does not work for this though, as that has an
implicit ".*" between elements of the expected list.

Meanwhile, we grew many tests that do [join [list ... "\r\n"]],
like this:

# start by listing all functions
gdb_test "record function-call-history /ci 1, +20" [join [list \
  "1\tmain\tinst 1,1" \
  "2\t  fun4\tinst 2,4" \
  "3\t    fun1\tinst 5,8" \
  "4\t  fun4\tinst 9,9" \
  "5\t    fun2\tinst 10,12" \
  "6\t      fun1\tinst 13,16" \
  "7\t    fun2\tinst 17,18" \
  "8\t  fun4\tinst 19,19" \
  "9\t    fun3\tinst 20,22" \
  "10\t      fun1\tinst 23,26" \
  "11\t    fun3\tinst 27,27" \
  "12\t      fun2\tinst 28,30" \
  "13\t        fun1\tinst 31,34" \
  "14\t      fun2\tinst 35,36" \
  "15\t    fun3\tinst 37,38" \
  "16\t  fun4\tinst 39,40" \
  ] "\r\n"]

Your multi_line looks like almost the same, except that it's
a tiny bit more lax:

proc multi_line { args } {
    return [join $args "\[\r\n\]*"]
}

That will accept _no_ newline between list elements, and
multiple newlines too.  How about making multi_line join
with strict "\r\n" too?  Then if you need to match one
empty line, you can do:

         [multi_line "line1" \
	             ""
                     "line3"]

and if you need multiple, you can always do:

         [multi_line "line1" \
	             "\[\r\n\]*"
                     "lineNN"]

> Let's do the following: Let's give people a week to comment on
> this, and if there are no objection, let's put it in ada.exp.
> If others agree that this should be in gdb.exp, then let's do that
> instead, and then add some documentation in our "testcase cookbook"
> wiki page about this routine.

Thanks,
Pedro Alves