Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
To: Andrew Burgess <aburgess@redhat.com>
Cc: Tom Tromey <tom@tromey.com>,
	 gdb-patches@sourceware.org,  Simon Marchi <simark@simark.ca>
Subject: Re: [PATCH] Skip gdb.dap/pause.exp on Solaris [PR34548]
Date: Tue, 25 Aug 2026 10:19:33 +0200	[thread overview]
Message-ID: <yddv78yehnu.fsf@CeBiTec.Uni-Bielefeld.DE> (raw)
In-Reply-To: <874igj26tf.fsf@redhat.com> (Andrew Burgess's message of "Mon, 24 Aug 2026 10:42:20 +0100")

[-- Attachment #1: Type: text/plain, Size: 2972 bytes --]

Hi Andrew,

>>> 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.

that certainly makes the most sense.

>> 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

... which wasn't completely certain as far as I understood Tom...

> 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.

Right: some of them already do their own checks for async support:

      gdb.base/async.exp
      gdb.base/bg-exec-sigint-bp-cond.exp
      gdb.base/interrupt-noterm.exp

but in those cases, async commands are a crucial part of the tests and I
couldn't easily use the new supports_target_async there.

There are certainly others that aren't handled yet.  Besides, there are
ca. 400 tests that currently time out on Solaris, massively increasing
make check time ;-(  I guess it's a major effort to reduce that number.

>>> 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.

I've now managed to get this working, although it took me some time to
wrap my head around gdb testing procedures.

Here's what I came up with.  The only change on x86-64-pc-linux-gnu was

+PASS: gdb.testsuite/gdb-caching-proc-consistency.exp: supports_target_async: consistency

while on Solaris it fully disabled the gdb.dap tests as expected.

---------------------------------------------------------------------------

As detailed in PR PR dap/34548, the gdb.dap/pause.exp test runs
indefinitely on Solaris.  To allow make check to finish, it needs to be
terminated manually.

Since DAP requires asynchronous execution support, this patch checks for
that and disables all gdb.dap tests if missing.

Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and
x86_64-pc-linux-gnu.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34548

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: testsuite-dap-async.patch --]
[-- Type: text/x-patch, Size: 1381 bytes --]

# HG changeset patch
# Parent  3fcec728f85b5d0cfef637d13368c88dad2e7bbc
Require async support for DAP tests [PR34548]

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -3070,6 +3070,10 @@ gdb_caching_proc with_system_readline {}
 }
 
 gdb_caching_proc allow_dap_tests {} {
+    if { ![supports_target_async] } {
+	return 0
+    }
+
     if { ![allow_python_tests] } {
 	return 0
     }
@@ -3908,6 +3912,39 @@ gdb_caching_proc supports_memtag {} {
     return 0
 }
 
+# Return 1 if target supports asynchronous execution, otherwise return 0.
+gdb_caching_proc supports_target_async {} {
+    global srcdir subdir gdb_prompt
+
+    set me "supports_target_async"
+
+    set src { int main() { return 0; } }
+    if {![gdb_simple_compile $me $src executable ""]} {
+	return 0
+    }
+
+    gdb_exit
+    gdb_start
+    gdb_reinitialize_dir $srcdir/$subdir
+    gdb_load $obj
+    if { ![runto_main] } {
+	return 0
+    }
+
+    set res 0
+    gdb_test_multiple "continue &" "" {
+	-re "Continuing..*" {
+	    set res 1
+	}
+	-re ".*Asynchronous execution not supported on this target..*" {
+	    set res 0
+	}
+    }
+    gdb_exit
+    remote_file build delete $obj
+    return $res
+}
+
 # Return 1 if catch syscall is supported, otherwise return 0.
 
 gdb_caching_proc supports_catch_syscall {} {

  reply	other threads:[~2026-08-25  8:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 14:18 Rainer Orth
2026-08-21 14:27 ` Tom Tromey
2026-08-22 20:25   ` Rainer Orth
2026-08-24  9:42     ` Andrew Burgess
2026-08-25  8:19       ` Rainer Orth [this message]
2026-08-25  8:22         ` Rainer Orth
2026-08-27 15:42         ` Tom Tromey
2026-08-28  8:49           ` [PATCH v2] Require async support for DAP tests [PR34548] Rainer Orth
2026-08-27 18:59         ` [PATCH] Skip gdb.dap/pauseR.exp on Solaris [PR34548] Andrew Burgess
2026-08-28  8:52           ` Rainer Orth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yddv78yehnu.fsf@CeBiTec.Uni-Bielefeld.DE \
    --to=ro@cebitec.uni-bielefeld.de \
    --cc=aburgess@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox