public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH 0/5] Various test suite fixes (mostly thread related)
@ 2023-02-17 20:38 John Baldwin
  2023-02-17 20:38 ` [PATCH 1/5] gdb.threads/multi-create: Double the existing stack size John Baldwin
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: John Baldwin @ 2023-02-17 20:38 UTC (permalink / raw)
  To: gdb-patches

I've been working on a series of patches for the FreeBSD native target
to fix various issues with multiprocessing over the past month or two.
During that time I have fixed a few issues in various tests I've
observed so far.  This series is just some of the test fixes.

Patch 1 fixes a Linux-specific assumption about PTHREAD_STACK_MIN.
There are a couple of other tests that also hardcoded
PTHREAD_STACK_MIN*2, but I haven't observed crashes with those on
FreeBSD so haven't adjusted those.  However, it might be more correct
to apply this same logic to the other tests as well.

Patch 2 fixes some Linux-specific assumptions about system call
catching.  The test still has some failures on FreeBSD that I might
need to adjust in the FreeBSD native target (FreeBSD reports a single
event for exec for example that is just the TARGET_WAITKIND_EXECD but
not a separate syscall exit event, and I think a similar issue might
also exist for fork events.)  However, FreeBSD now passes at least
some of the tests compared to passing zero before.

Patches 3 and 4 fix synchronization issues where tests were assuming
that if the main thread calls pthread_create and then exits, the new
thread will start executing bofore the main thread exits.  That isn't
guaranteed to be true as a given kernel scheduler may create the new
thread and place it on a run queue but not preempt to it and return to
the main thread letting it exit before the new thread runs and reports
an event to say it has been born.  Use a pthread_barrier to ensure the
requirements of the test instead.  There are likely other instances of
this, these are just the two I've noticed so far.  I wonder if Linux
reports thread creation events when the thread is created rather than
when it starts executing which might explain why these tests have this
assumption?

The last patch is a bit more of a RFC and probably not really the way
we want to fix the issue.  Some tests assume that the format of 'info
threads' is to have thread identifiers start with "Thread".  However,
some targets use a different format.  For example FreeBSD's native
target refers to threads as "LWP <nnnn>".  There are some existing
tests that use a looser regex here already rather than requiring the
word "Thread".  I wonder if we want to define a helper macro or
variable or like to contain the regex to use for matching on a valid
thread identifier instead?

John Baldwin (5):
  gdb.threads/multi-create: Double the existing stack size.
  gdb.base/catch-syscall.exp: Remove some Linux-only assumptions.
  gdb.threads/execl.c: Ensure all threads are started before execl.
  gdb.threads/next-bp-other-thread.c: Ensure child thread is started.
  gdb tests: Allow for "LWP" in thread IDs from info threads.

 gdb/testsuite/gdb.base/catch-syscall.c        |  4 ++
 gdb/testsuite/gdb.base/catch-syscall.exp      | 48 +++++++++++++++++--
 .../gdb.multi/multi-target-thread-find.exp    |  2 +-
 gdb/testsuite/gdb.python/py-thrhandle.exp     |  2 +-
 .../gdb.server/stop-reply-no-thread-multi.exp |  8 ++--
 gdb/testsuite/gdb.threads/execl.c             |  8 ++++
 gdb/testsuite/gdb.threads/execl.exp           |  6 +--
 .../gdb.threads/fork-child-threads.exp        |  2 +-
 .../gdb.threads/fork-thread-pending.exp       | 16 +++----
 .../gdb.threads/info-threads-cur-sal.exp      |  8 ++--
 .../gdb.threads/interrupt-while-step-over.exp |  2 +-
 gdb/testsuite/gdb.threads/leader-exit.exp     |  2 +-
 gdb/testsuite/gdb.threads/manythreads.exp     |  2 +-
 gdb/testsuite/gdb.threads/multi-create.c      |  8 +++-
 .../gdb.threads/next-bp-other-thread.c        |  9 ++++
 .../gdb.threads/no-unwaited-for-left.exp      |  4 +-
 gdb/testsuite/gdb.threads/non-ldr-exc-2.exp   |  2 +-
 gdb/testsuite/gdb.threads/pthreads.exp        |  8 ++--
 .../signal-command-handle-nopass.exp          |  2 +-
 ...ignal-command-multiple-signals-pending.exp |  2 +-
 .../signal-delivered-right-thread.exp         |  2 +-
 gdb/testsuite/gdb.threads/signal-sigtrap.exp  |  4 +-
 gdb/testsuite/gdb.threads/staticthreads.exp   |  2 +-
 .../gdb.threads/thread-specific-bp.exp        |  2 +-
 gdb/testsuite/gdb.threads/thread-specific.exp |  4 +-
 gdb/testsuite/gdb.threads/tls.exp             | 12 ++---
 gdb/testsuite/gdb.trace/report.exp            |  2 +-
 gdb/testsuite/gdb.trace/strace.exp            |  2 +-
 28 files changed, 120 insertions(+), 55 deletions(-)

-- 
2.38.1


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-03-03 19:16 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-17 20:38 [PATCH 0/5] Various test suite fixes (mostly thread related) John Baldwin
2023-02-17 20:38 ` [PATCH 1/5] gdb.threads/multi-create: Double the existing stack size John Baldwin
2023-02-17 20:38 ` [PATCH 2/5] gdb.base/catch-syscall.exp: Remove some Linux-only assumptions John Baldwin
2023-02-17 20:38 ` [PATCH 3/5] gdb.threads/execl.c: Ensure all threads are started before execl John Baldwin
2023-02-17 20:38 ` [PATCH 4/5] gdb.threads/next-bp-other-thread.c: Ensure child thread is started John Baldwin
2023-02-17 20:38 ` [PATCH 5/5] gdb tests: Allow for "LWP" in thread IDs from info threads John Baldwin
2023-03-03 17:59 ` [PING] [PATCH 0/5] Various test suite fixes (mostly thread related) John Baldwin
2023-03-03 19:16 ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).