From patchwork Fri Dec 29 10:41:56 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Natalia Saiapova X-Patchwork-Id: 56555 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3CBD63858402 for ; Fri, 29 Dec 2023 10:43:13 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.126]) by sourceware.org (Postfix) with ESMTPS id 625E13858D33 for ; Fri, 29 Dec 2023 10:42:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 625E13858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 625E13858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=134.134.136.126 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703846544; cv=none; b=tbaKSZjAbda1pNzCHV+ni1JM2/1jVVh5vhtms9pmVQLXXxAulySUNUAtNmd2mWUWYkHmrOTpGcCbBlvzkQI5Z1qMBFP3yF8B8cu9BlCERbFIap+qLxZSlPNmulhtykgg2YdgqzoSDNze/5wCHSAnZ8ukVWttbIYKeSj68s1VDOQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703846544; c=relaxed/simple; bh=btZDg1d1JngM1s3AMdMm9p69y52IpFGtqf3XEhmUCQM=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=xzLb45puDQIyaooE3t16fCj9oAKXaLemr9Mk5K/VbQ6hYu83+sAf9utN8/+Bs90eln8QnpUi4UNW/I0EtD4QuHN9Yb1HkkmUrTYi5mlyLu4wGLq8DxtIYdnxhel5aRWC8HVWGJ2kphh5XBQiQC1JbBESX+1G5+agYWOvc6DYRUo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1703846541; x=1735382541; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=btZDg1d1JngM1s3AMdMm9p69y52IpFGtqf3XEhmUCQM=; b=YKTpl5eD2xc3OWiQ/XFgQb/xKpHij775x/5sWLZMks9ktWfYFSU0A67/ etHnOMKAAsL1cNlqJmE2qCs8hMapr+a7YNEANqhHCCfT9WqCwKM4UIicI pdvh7reAy/4w29M+P7JJUJ9mhYMhPSu5p2UMZEh4rjqsJGAbSbqZuWtxS /Awtqr5fPQo+iwhvApLJwh3jJUgwEq1fDe7jaGvLRKPpl+iTYojZ+3sqE ZGDcsMI+uAqiueXp0j09SsQHciH3XAAVSoo8xGGQ7oonDpGOthGmoPFAL kuGjDMMJ6yHRrf8QSxTCnXZGA3KnpV7XdUfnVrei7RNsCzOHvPS4c+60s Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10937"; a="381613082" X-IronPort-AV: E=Sophos;i="6.04,314,1695711600"; d="scan'208";a="381613082" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2023 02:42:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10937"; a="755000233" X-IronPort-AV: E=Sophos;i="6.04,314,1695711600"; d="scan'208";a="755000233" Received: from unknown (HELO localhost) ([10.211.177.238]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Dec 2023 02:42:19 -0800 From: Natalia Saiapova To: gdb-patches@sourceware.org Cc: tankut.baris.aktemur@intel.com Subject: [PATCH 0/6] Refinement of scheduler-locking settings Date: Fri, 29 Dec 2023 10:41:56 +0000 Message-Id: <20231229104202.7878-1-natalia.saiapova@intel.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Hi all, I want to come back to the topic I raised a few years ago about the scheduler locking during the inferior calls. For the history, here are the links to the previous threads: https://sourceware.org/pipermail/gdb/2019-June/047996.html https://sourceware.org/pipermail/gdb/2019-July/048003.html > In multithreaded program, when several threads are stopped at a > breakpoint and > scheduler-locking mode is not 'on', there might be unexpected thread > switches > during an inferior call evaluation. If such thread switching occurs, > the evaluation of the inferior call is abandoned: > > ~~~ > (gdb) run > Thread 1 "a.out" hit Breakpoint 2, main._omp_fn.0(void) () at > multi-omp.cpp:18 > 18 std::cout << > omp_get_thread_num(); > (gdb) call do_something() > [Switching to Thread 0x7ffff6327700 (LWP 32498)] > > Thread 3 "a.out" hit Breakpoint 2, main._omp_fn.0(void) () at > multi-omp.cpp:18 > 18 std::cout << > omp_get_thread_num(); > The program stopped in another thread while making a function call > from GDB. > Evaluation of the expression containing the function > (do_something()) will be abandoned. > When the function is done executing, GDB will silently stop. > ~~~ The problem is that only scheduler-locking "on" can lock the scheduler for inferior calls, which is quite restrictive for debugging. A possible solution would be to add a new option, e.g., "eval", to the existing "set scheduler-locking", but this might often be used together with the "step" option, so a user would need to always remember to switch the scheduler-locking to the correct option. I chose a different and a more invasive direction and prepared a set of patches that introduce a finer control over the scheduler locking. With that, a user can choose for which types of commands the scheduler should be locked and mix different locking strategies together. For the moment, I distinguish two modes (normal and replay) and three command types (continuing, stepping, and inferior call evaluation). This way, we can lock the scheduler during the stepping and inferior calls, but leave it unlocked for "continue". I tried to be backwards compatible, so all existing scheduler-locking settings are expected to be preserved, however, the "show" commands had to be changed. I will be happy to hear your opinion on the proposed change to the scheduler locking interface! Regards Natalia My base commit is 3bb1944a5a0 asan: buffer overflow in loongarch_elf_rtype_to_howto Natalia Saiapova (6): gdb: use schedlock_applies in user_visible_resume_ptid. gdb, cli: remove left-over code from "set_logging_on". gdb, cli: pass the argument of a set command to its callback. gdb: change the internal representation of scheduler locking. gdb: add commands to control scheduler locking. gdb: add eval option to lock the scheduler during infcalls. gdb/NEWS | 21 + gdb/cli/cli-logging.c | 5 - gdb/cli/cli-setshow.c | 2 +- gdb/doc/gdb.texinfo | 68 ++- gdb/infrun.c | 410 +++++++++++++++--- .../gdb.mi/user-selected-context-sync.exp | 22 +- .../gdb.threads/hand-call-in-threads.exp | 8 +- .../multiple-successive-infcall.exp | 5 +- gdb/testsuite/gdb.threads/schedlock.exp | 103 ++++- gdb/testsuite/lib/gdb.exp | 57 ++- 10 files changed, 580 insertions(+), 121 deletions(-)