From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id +NhBCNlhE2eoGxMAWB0awg (envelope-from ) for ; Sat, 19 Oct 2024 03:38:01 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=QUhpRCiG; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id F2F791E35F; Sat, 19 Oct 2024 03:38:00 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_BLOCKED,RCVD_IN_VALIDITY_CERTIFIED,RCVD_IN_VALIDITY_RPBL, RCVD_IN_VALIDITY_SAFE,URIBL_BLOCKED,URIBL_DBL_BLOCKED_OPENDNS 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 52FAA1E05C for ; Sat, 19 Oct 2024 03:38:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BD98C3858C2B for ; Sat, 19 Oct 2024 07:37:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BD98C3858C2B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1729323479; bh=XRcaxYW+ktJwV5EaQ0ejaa0DAAPpOJgyPGuUTR8JYnA=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=QUhpRCiGeMsR6LP0YgO6LXlabWsCBRtM0hUpZchGS1aIJEmXZ1Ab2tQtsXohRvodv L/t56nNrtkhNQQBxBoMbjvwXHjQVQdlrhhg+2VCVJ9F8yZq1BcveDfhshwI6JmzS6G vvkC9AuXypmrQ84kaI/UDXlLHr7tzVkg1dxmhcu8= Received: from smtp2-g21.free.fr (smtp2-g21.free.fr [IPv6:2a01:e0c:1:1599::11]) by sourceware.org (Postfix) with ESMTPS id 0B3053858D37 for ; Sat, 19 Oct 2024 07:37:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0B3053858D37 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0B3053858D37 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729323443; cv=none; b=c4ub0yE6jJPlsAmQ3PIpH0jej0rr3ISzqUhKjKt7T/z1ymas/S8DiXo1a/B3+VvcgVo8O7tvEDPk1mFc+glrH4a+xHljJxAfLUMRYnqw7lCRw5xSddcdqwk9awHtnNrHwtovarfwYF4MmsPebAQ+ilePGSNF1vfXwoXjRWNLiyI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1729323443; c=relaxed/simple; bh=XRcaxYW+ktJwV5EaQ0ejaa0DAAPpOJgyPGuUTR8JYnA=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=vfgmwGgq57rjTD4WJejHCgcTQFofM7SMKNP0RxxxKRJHfjjPFvGHCoX4YORWE+xKxFEuWZoZPx2d/Gq151mNq6s0EnvPRolPyTquph77rxkyfEdVXlLeCZ5Q5++Pd8rTbBguKEi2WeOsgl8MGOLKCn695NGF3NRntUQve4NNnEg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from localhost (unknown [82.64.135.138]) by smtp2-g21.free.fr (Postfix) with ESMTP id 859DB2003D0 for ; Sat, 19 Oct 2024 09:37:20 +0200 (CEST) Received: by localhost (Postfix, from userid 1000) id 69DCD40042; Sat, 19 Oct 2024 09:35:40 +0200 (CEST) Date: Sat, 19 Oct 2024 09:35:40 +0200 To: gdb@sourceware.org Subject: Feature suggestion: location conditioned watchpoint Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Etienne Buira via Gdb Reply-To: Etienne Buira Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" Hi all, I tried to debug memory corruption issue with gdb, using watchpoints, and as the bug appeared rarely, i wish i could state "break on this memloc write, if it is not this known good location". I searched the docs for conditions and convenience variables, but could not find anything useful. Ideally, i would like to issue a command like: condition WPNUM !(location path/to/myfile.c:42) If there is already a way to do this, i'd like to hear about it, or please consider it as feature suggestion. Unfortunately, the bug did not show up when ran under gdb supervision, even after enabling memory space randomisation, but that's another topic. Regards.