From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0BKEAnr8RmetmQEAWB0awg (envelope-from ) for ; Wed, 27 Nov 2024 06:03:22 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=QVpW9kMc; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 02B4E1E097; Wed, 27 Nov 2024 06:03:22 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 33E381E05C for ; Wed, 27 Nov 2024 06:03:21 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CB9B83858C53 for ; Wed, 27 Nov 2024 11:03:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CB9B83858C53 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=QVpW9kMc Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.10]) by sourceware.org (Postfix) with ESMTPS id 8D0603858C42 for ; Wed, 27 Nov 2024 11:01:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8D0603858C42 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 8D0603858C42 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=192.198.163.10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732705305; cv=none; b=jPSn6f1qVf/UifS/s6klH6GS1+tj7rjt9UZOAc+Y6GJEiW7BHIJa6H4Ua7+UMTya3vWQgdLtYF7Ix8X7ZaKfqXXyuP3TIS1GEm1nwDdwZFm04mA+XppCyUMRIdwIVDdnk8yje+hZCI7tQ3Yn38TYHcxaFLOir8mBR9r94IToh6M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1732705305; c=relaxed/simple; bh=np9dykVuAepc+7P1jSr/ixTvCXdLsK8+eC8IYgdbWaY=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=cwsdmjre/an6szxxGYB4FbG8vsZwKkavEBe4pBrh/yrwXsfEvQ0aZMHIqsZW+Sxe59+XPRXKUCUKbv2Z7871GuzfjqQGfiIHWuHGMw18+9PBXW571O2p/QzaeJdzUyZU7mpBGbY4S8fpHluYqGw0FrqgLHpx917seGy8//wT/pU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D0603858C42 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1732705305; x=1764241305; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=np9dykVuAepc+7P1jSr/ixTvCXdLsK8+eC8IYgdbWaY=; b=QVpW9kMcTzgfDRvBgla/h1DmqEiRGneeSl3zN7fR56XOhfX4kMZqSo1x PXItkjNFPCSZ06xbqTXRKlhy/50WQAR6TswCGpdaNBSMFY8eiK+1rtHEq kWQT3nk7mUt6kLNVsuJMATDt7RmuUwL88ndGDRrdNeaJFE/lXpwPAIDOR 97cJlec7bOm/9GU6fzEqIj7owqbNca21a9vBWYcbO+jLRxpegZjqx2nAc UGfPU9YgaPcRDHLqLJuYQRZqvEg7lUFpPPqt1izMRTBja/6NCp7jnfCYE bOKoxHaiSfjWyjiC8s/GMkHf1yBpTMzKRdvyxeiZ088LJ0RwSfJp65iZ2 A==; X-CSE-ConnectionGUID: fmKPx+GaR5Kr0CAFq+e3Qg== X-CSE-MsgGUID: LP2SkifzQfikrJuFT37MFQ== X-IronPort-AV: E=McAfee;i="6700,10204,11268"; a="44292003" X-IronPort-AV: E=Sophos;i="6.12,189,1728975600"; d="scan'208";a="44292003" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by fmvoesa104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2024 03:01:43 -0800 X-CSE-ConnectionGUID: lrFsN0XgSHi+7eYX4586IQ== X-CSE-MsgGUID: qcCrczjRQf2DoIQl5PuELQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,189,1728975600"; d="scan'208";a="122873651" Received: from dut1505dg2frd.igk.intel.com (HELO localhost) ([10.102.46.29]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Nov 2024 03:01:42 -0800 From: Klaus Gerlicher To: gdb-patches@sourceware.org, aburgess@redhat.com Subject: [PATCH v3 0/1] gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints Date: Wed, 27 Nov 2024 11:01:31 +0000 Message-Id: <20241127110132.125667-1-klaus.gerlicher@intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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~public-inbox=simark.ca@sourceware.org Hi Andrew, thanks for the feedback. You replied: > But, I wonder if there's a different approach that could be used? > > I assume that your out of tree architecture with these imprecise page > faults has a new gdbarch to represent it. > > You are limiting the SIGSEGV -> SIGTRAP conversion because, I assume, > you've hit cases where a SIGSEGV occurs and then your target has run on > and reported the stop at the address of a user breakpoint. But all > you're really doing is reducing the scope for errors. It could be the > case that the SIGSEGV is reported at the site of an internal breakpoint, > and then you'll still have issues. > > So what if, instead, you added a new gdbarch method, something like: > > bool gdbarch_has_imprecise_page_faults (struct gdbarch *gdbarch); > > The default for this, and for all currently in-tree targets, would be to > return true. For your target this will return false. > > Then in this code we would do: > > if (ecs->ws.kind () == TARGET_WAITKIND_STOPPED > && (ecs->ws.sig () == GDB_SIGNAL_ILL > || (ecs->ws.sig () == GDB_SIGNAL_SEGV > !gdbarch_has_imprecise_page_faults (gdbarch)) > || ecs->ws.sig () == GDB_SIGNAL_EMT)) > > How does this approach sound? I think for now this would be a viable solution and I implemented it in the V3 patch. However, we had a little discussion internally and we were wondering if this now feels more like a workaround in a workaround. It seems to me that the conversion of any of these signals should really be only done for a specific target. Even though the SIG_ILL and SIG_EMT conversions obviously have no side effects for most targets, I would think these should be avoided. Do you think there's a way to limit these more specifically or are we unsure which targets actually need these? Maybe some of the users are already obsolete? I would assume it would be difficult to limit to a specific target when we used the remote target since we would then have to update GDB server to also support this. I'm of course fine if we fix it with the architecture method but maybe others would disagree? Thanks Klaus Gerlicher, Klaus (1): gdb: avoid conversion of SIGSEGV to SIGTRAP on user breakpoints gdb/gdbarch-gen.c | 22 ++++++++++++++++++++++ gdb/gdbarch-gen.h | 7 +++++++ gdb/gdbarch_components.py | 12 ++++++++++++ gdb/infrun.c | 4 +++- 4 files changed, 44 insertions(+), 1 deletion(-) -- 2.34.1 Intel Deutschland GmbH Registered Address: Am Campeon 10, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928