From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2607:f138:0:13::2]) by sourceware.org (Postfix) with ESMTPS id CBF18385828E for ; Fri, 17 Feb 2023 20:38:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CBF18385828E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=FreeBSD.org Received: from gimli.baldwin.net (c-98-35-126-114.hsd1.ca.comcast.net [98.35.126.114]) by mail.baldwin.cx (Postfix) with ESMTPSA id 0D6A41A84BF2 for ; Fri, 17 Feb 2023 15:38:23 -0500 (EST) From: John Baldwin To: gdb-patches@sourceware.org Subject: [PATCH 0/5] Various test suite fixes (mostly thread related) Date: Fri, 17 Feb 2023 12:38:13 -0800 Message-Id: <20230217203818.11287-1-jhb@FreeBSD.org> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (mail.baldwin.cx [0.0.0.0]); Fri, 17 Feb 2023 15:38:24 -0500 (EST) X-Virus-Scanned: clamav-milter 0.103.1 at mail.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KHOP_HELO_FCRDNS,SPF_HELO_PASS,SPF_SOFTFAIL,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 ". 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