From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11442 invoked by alias); 28 Sep 2012 17:44:25 -0000 Received: (qmail 11434 invoked by uid 22791); 28 Sep 2012 17:44:24 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Sep 2012 17:44:13 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8SHiBdG014105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Sep 2012 13:44:11 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q8SHi9tn032422; Fri, 28 Sep 2012 13:44:10 -0400 Message-ID: <5065E1E9.5040204@redhat.com> Date: Fri, 28 Sep 2012 17:44:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] new tracepoint downloaded MI notification. References: <1348793347-12556-1-git-send-email-yao@codesourcery.com> <1348793347-12556-3-git-send-email-yao@codesourcery.com> In-Reply-To: <1348793347-12556-3-git-send-email-yao@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-09/txt/msg00687.txt.bz2 On 09/28/2012 01:49 AM, Yao Qi wrote: > +@item =tracepoint-downloaded,id="@var{number}",address="@var{addr}" > +Reports that a tracepoint was downloaded to target. The @var{number} > +is the ordinal number of the tracepoint. The @var{addr} is the > +address where tracepoint was downloaded. The "address where tracepoint was downloaded" makes me think this returns the address in gdbserver's memory that holds the tracepoint object. But it's not, it's the tracepoint's address, as in the address the tracepoint is set at in the inferior. Took me a second to recall, but the reason the address is necessary is multi-location tracepoints -- a tracepoint on the target is identified by the { number, address } tuple. We don't send over the location's sub number (like 1.1, 1.2, etc.). Should we mention this somewhere (other than at the tracepoint packets description), so frontend people don't wonder whether they can ignore the address field, and why aren't the other fields of the tracepoint (like spec string) included? -- Pedro Alves