Re: [PATCH] Add mi-threads-interrupt.exp test (PR 20039)

[Simon Marchi <simon.marchi@ericsson.com>]

On 16-05-04 05:20 AM, Pedro Alves wrote:
> On 05/03/2016 10:57 PM, Pedro Alves wrote:
>> AFAICS, the test relies on "set mi-async off".  Could you make sure that
>> if you run it against a board file that forces that on, the test either
>> passes (probably with -exec-interrupt in async mode) or is skipped?
>> See mi_detect_async and the async global.
> 
> Woke up this morning realizing that I hadn't done this for so long
> myself that I had forgotten how I used to do it.  We don't really
> need a board file -- as described in the TestingGDB wiki page [1], 
> we can use GDBFLAGS from the command line for this:
> 
>  $ make check RUNTESTFLAGS="GDBFLAGS='-ex set\ mi-async\ on'" TESTS="gdb.mi/mi-threads-interrupt.exp"
>  ...
>  FAIL: gdb.mi/mi-threads-interrupt.exp: interrupt #1 (unknown output after running)
>  FAIL: gdb.mi/mi-threads-interrupt.exp: continue #2
> 
> [1] https://sourceware.org/gdb/wiki/TestingGDB
> 
> Thanks,
> Pedro Alves
> 

Why would it make sense to set async on in a board file?  My understanding is
that the board file defines the debug target side of things, but the fact that MI
is sync or async (or that we use MI at all) is not decided by the debug target.

I would think that it's up to the tests to set async however they want it,
depending on what they test.  In this particular case, wouldn't it be better
to run both the test in sync and async modes, as we do often for non-stop?

So, for example:

proc test_continue_interrupt { async } {
  with_test_prefix "async=$async" {
    ...
  }
}

foreach async {on off} {
  test_continue_interrupt $async
}

It hacked the test quickly, and it shouldn't be too hard to do.

Thanks,

Simon