From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83462 invoked by alias); 11 Nov 2015 18:01:07 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 83447 invoked by uid 89); 11 Nov 2015 18:01:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailuogwdur.emc.com Received: from mailuogwdur.emc.com (HELO mailuogwdur.emc.com) (128.221.224.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 11 Nov 2015 18:01:05 +0000 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tABI10md000509 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 11 Nov 2015 13:01:01 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com tABI10md000509 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com tABI10md000509 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd56.lss.emc.com (RSA Interceptor) for ; Wed, 11 Nov 2015 13:00:27 -0500 Received: from mxhub07.corp.emc.com (mxhub07.corp.emc.com [128.222.70.204]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id tABI0itw017440 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Nov 2015 13:00:44 -0500 Received: from mx37a.corp.emc.com ([169.254.1.117]) by mxhub07.corp.emc.com ([128.222.70.204]) with mapi; Wed, 11 Nov 2015 13:00:43 -0500 From: "taylor, david" To: "gdb@sourceware.org" Date: Wed, 11 Nov 2015 18:01:00 -0000 Subject: (hardware) watchpoints and actions Message-ID: <64A9FD4472059B48AC8F38981B7DA5342EF9BD5F8C@MX37A.corp.emc.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public X-SW-Source: 2015-11/txt/msg00015.txt.bz2 For instructions, GDB has breakpoints and tracepoints. For data, GDB has watchpoints. It would be nice if there was a data equivalent of tracepoint= s. There is processor support for a limited number of small locations to be wa= tched. The goal is to run at full speed until a watched location is accessed in so= me prescribed manner. At that time, like a tracepoint, execute some actions to collect information and then continue at full speed. It's sort of like a hardware watchpoint with actions attached. For lack of= a better name, we call them 'data tracepoints'. The current implementation is somewhat of a kludge and done without any GDB modifications. The GUI checks whether the address given for the tracepoint= is a code address or a data address. For instructions, it does what it has alwa= ys done, for data, it does some kludges to avoid getting an error from GDB and also = 'overloads' some tracepoint fields. I'd like for it to be a part of GDB and also to avoid the kludges. Two questions immediately come to mind: . what should the GDB user interface be? . what should the remote protocol messages be? Opinions? Thoughts?