Re: [PATCH] Skip gdb.dap/pause.exp on Solaris [PR34548]

[Andrew Burgess <aburgess@redhat.com>]

Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> Hi Tom,
>
>>>>>>> "Rainer" == Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>>
>> Rainer> As detailed in PR PR dap/34548, the gdb.dap/pause.exp test runs
>> Rainer> indefinitely on Solaris.  To allow make check to finish, it needs to be
>> Rainer> terminated manually.
>>
>> Rainer> To avoid this, this patch skips the test.
>>
>> Rainer> Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and
>> Rainer> x86_64-pc-linux-gnu.
>>
>> Rainer> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34548
>>
>> Rainer> Ok for trunk?
>>
>> This is fine, but in the bug you mentioned other reports about target
>> async not working.
>
> not actually reports, just ca. 100 instances of the
>
> Asynchronous execution not supported on this target.
>
> message in the full testsuite log.  Some of them already turn the tests
> UNSUPPORTED, while others cause the tests to FAIL.
>
>> So maybe DAP testing should be entirely disabled for Solaris?
>
> Like just returning 0 from allow_dap_tests on Solaris?  Or doing so for
> all targets lacking async support?

I'd suggest adding:

  # Return true for targets that support target async,
  # otherwise return false.
  proc supports_target_async {} {
    # ...
  }

then return 0 from allow_dap_tests for any target that returns false
from the above.  That would seem better than just having a selective fix
in the pause.exp file.

>
> Here's a breakdown of gdb.dap results on Solaris:
>
>       8 ERROR
>      11 FAIL
>     713 PASS
>       8 PATH
>       8 UNRESOLVED
>       2 UNSUPPORTED
>
> I can't tell if it's still useful this way.

I haven't checked by a lot of these passes are going to be general
boiler plate stuff.  If DAP support is known to require target async
then my personal feeling is that we'd be better just skipping those
tests on Solaris.  There's plenty of testing done on other targets where
target async is supported.

>
>> Rainer> This might also be a candidate for the gdb-18 branch.
>>
>> It's fine by me.
>
> Thanks.  I'll way for approval from a release manager then.

It might be worth getting the above changes made first.  If you don't
have time then let me know and I'll take care of it.

Thanks,
Andrew