Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Tom de Vries <tdevries@suse.de>, gdb-patches@sourceware.org
Subject: Re: [PATCH] [gdb/tdep] Don't call WaitForSingleObject with INFINITE arg
Date: Fri, 6 Jun 2025 16:14:22 +0100	[thread overview]
Message-ID: <ce63bdab-d56d-4fcd-bae8-01df1c7fde37@palves.net> (raw)
In-Reply-To: <4311a30a-51cc-4054-8219-48f895bd962f@suse.de>

On 2025-06-06 08:12, Tom de Vries wrote:

> FWIW, I've ran the testsuite again, and got stuck this time at gdb.base/catch-fork-kill.exp.  In this case, the problem didn't seem to be gdb, but lingering test execs.  After killing those manually using "kill -9", the test-case finished.
> 
> The hang can be fixed by adding a missing "require supports_catch_syscall".
> 
> I was wondering, I saw you mention "I've got another series of patches to improve such tests and skip others, and that's what I've been testing with".  Do you have similar fixes in that series?  If so, can you submit them, or share them in a branch?
> 

For fork-related tests, I added allow_fork_tests to be used with require, and
sprinkled that throughout.  There is no way currently for the debugger to be notified
of forks and execs.  There is no protocol between debugger and Cygwin for that.
So all fork tests fail.

So for gdb.base/catch-fork-kill.exp in particular, that's what I did:

 diff --git a/gdb/testsuite/gdb.base/catch-fork-kill.exp b/gdb/testsuite/gdb.base/catch-fork-kill.exp
 index 0fd853b9085..224a8dfec89 100644
 --- a/gdb/testsuite/gdb.base/catch-fork-kill.exp
 +++ b/gdb/testsuite/gdb.base/catch-fork-kill.exp
 @@ -32,6 +32,8 @@
 
  standard_testfile
 
 +require allow_fork_tests


And then, the Windows backend doesn't currently support multi-process at all,
so all tests exercising that fail, sometimes with cascading timeouts.  So I added
allow_multi_inferior_tests for that.

I did initially try to fix the testcases individually initially, one by one, to
gracefully handle fork-related (and multi-inferior-related) things failing and
bailing out early, but it was turning into a time sink for not much gain,
and I then decided to apply the "require" big hammer to move on.

Here's the subject lines of the testsuite-related patches (and gdb patches that the
tests depend on) that I'd like to submit, which mention the testcase names.
Some are WIP, and some are hacks that probably should be done differently.

I'll need a bit to clean them up somewhat, add commit logs, etc. and
either post them to the list or push them to a branch.  I should probably do this
piecemeal, a patch at a time.

# gdb.multi/attach-no-multi-process.exp: Detect no remote non-stop
# gdb testsuite: Introduce allow_fork_tests and use it throughout
# gdb testsuite: Introduce allow_multi_inferior_tests and use it throughout
# Make gdb.threads/watchthreads.exp fetch registers of all threads
# Windows GDB: Avoid hang second attach (gdb.base/attach.exp)
# gdb.threads/schedlock.exp: Expected SIGTRAP too
# Windows all-stop, interrupt with "stopped" instead of SIGTRAP
# gdb.threads/schedlock.exp: handle "stopped" too (to squash)
# Extra "maint set show-debug-dregs" debug output (submit separately)
# Fix gdb.threads/multiple-successive-infcall.exp on Windows (depends on schedlock)
# Software watchpoints and threaded inferiors (submit independently)
# Skip gdb.base/libsegfault.exp on Cygwin (submit independently)
# gdb.threads/thread-execl, don't re-exec forever (submit independently)
# Support core dumping testcases with Cygwin's dumper (submit independently)
# Skip gdb.base/many-headers.exp on Cygwin (submit independently)
# Fix gdb.threads/multiple-successive-infcall.exp on Cygwin (hack)
# Adjust gdb.base/sigall.exp for Cygwin (submit independently)
# Adjust gdb.threads/schedlock.exp for Cygwin (submit independently)
# Adjust gdb.threads/multiple-step-overs.exp for Cygwin (submit independently)
# Adjust gdb.threads/step-over-trips-on-watchpoint.exp for Cygwin (submit independently)
# Adjust gdb.cp/cpexprs.exp for Cygwin (submit independently)
# remote target pid_to_string for gdb.server/ext-attach.exp (incomplete)
# Adjust gdb.base/bp-cond-failure.exp for Cygwin (submit separately)
# Adjust gdb.base/bp-permanent.exp for Cygwin (submit separately)
# Fix gdb.arch/amd64-watchpoint-downgrade.exp for Cygwin (submit separately)
# announce attach should be earlier (submit separately)
# Convert gdb.base/watchpoint-hw-attach.exp to spawn_wait_for_attach (submit separately)

Pedro Alves

  reply	other threads:[~2025-06-06 15:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05 15:03 Tom de Vries
2025-06-05 16:15 ` Pedro Alves
2025-06-05 16:25   ` Pedro Alves
2025-06-06  6:27     ` Tom de Vries
2025-06-06  7:12   ` Tom de Vries
2025-06-06 15:14     ` Pedro Alves [this message]
2025-06-06 15:27       ` Pedro Alves
2025-06-09 17:52         ` Pedro Alves
2025-06-10  7:13           ` Tom de Vries
2025-06-06 13:11   ` Pedro Alves
2025-06-10  7:13     ` Tom de Vries
2025-06-10  9:51       ` Pedro Alves

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=ce63bdab-d56d-4fcd-bae8-01df1c7fde37@palves.net \
    --to=pedro@palves.net \
    --cc=gdb-patches@sourceware.org \
    --cc=tdevries@suse.de \
    /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