From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20582 invoked by alias); 17 May 2016 00:31:00 -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 20567 invoked by uid 89); 17 May 2016 00:30:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,SPF_PASS autolearn=ham version=3.3.2 spammy=customer's, designer, tricks, U*gdb X-HELO: usplmg21.ericsson.net Received: from usplmg21.ericsson.net (HELO usplmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 17 May 2016 00:30:49 +0000 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 17.67.03614.5066A375; Tue, 17 May 2016 02:29:57 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 16 May 2016 20:30:46 -0400 From: Marc Khouzam To: David Taylor , "gdb@sourceware.org" Subject: RE: tracepoints -- DWARF and tstart Date: Tue, 17 May 2016 00:31:00 -0000 Message-ID: References: <19272.1463426651@usendtaylorx2l> In-Reply-To: <19272.1463426651@usendtaylorx2l> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-05/txt/msg00005.txt.bz2 > From: gdb-owner@sourceware.org [gdb-owner@sourceware.org] on behalf of Da= vid Taylor [dtaylor@emc.com] > Sent: May 16, 2016 3:24 PM > To: gdb@sourceware.org > Subject: tracepoints -- DWARF and tstart >=20 > When doing a trace experiment, GDB waits until you type 'tstart' to > generate the agent byte code expressions that it will send to the GDB > stub running on the remote target. >=20 > This might be okay if the conversion never produced an error. >=20 > Alas, it *CAN* produce an error *AND* GDB is rather stingy with the > information that it shares with the user when this happens. >=20 > Imagine a trace experiment where you have defined half a dozen > tracepoints, each with some collection actions. You type >=20 > tstart >=20 > and GDB responds with something like >=20 > DWARF operator DW_OP_GNU_implicit_pointer cannot be translated to an > agent expression. >=20 > and the trace experiment is *NOT* started. >=20 > You've got a problem to debug. You are trying to run a trace experiment > to collect information to debug the problem. And GDB is being rather, > shall we say, unhelpful. >=20 > Ideal would be to get the errors, if any, when you type the > ending the particular 'collect' action. >=20 > Second best would be to get them, along with which collect was the > problem, when you type the 'end' ending the set of actions associated > with the tracepoint. >=20 > Getting it with 'tstart', while not ideal, would be a lot better if it > told you *WHICH* tracepoint and *WHICH* collect action are the cause of > the problem. >=20 > And, if they are going to occur at 'tstart' time, a warning would be > nicer. That is, allow the experiment to run without that particular > variable / expression. If the expression is '$locals', then warning > about whichever variable is the problem and collecting the rest would > be nice. >=20 > My current thinking is to do the last option above (it seems the easiest > / quickest) and think about what would be required to give the error > earlier. >=20 > Thoughts? I completely agree that the current error reporting for tracepoints gives a very poor user experience. Besides the lack of clarity on how to fix the error, waiting for tstart is problematic. When the user types tstart, it is time to start tracing. The user may have waited until a particular time when the error can easily be reproduced to trigger the tracing. When tstart fails, it delays the start of the tracing experiment and could cause the user to miss the time window. One can imagine a real world scenario where a designer sets up all the tracepoints at a customer site and leaves the enabling of tracing (tstart) to a less technical person once night time comes and the customer's computers can be monitored freely. If the tstart fails, then the developer is not on site anymore and fixing it may have to wait until the next day. It would be much more user friendly to know the tracepoints have an error as soon as they are created. IIRC, this is not trivial since tracepoints are not actually pushed to the target until tstart. But I hope there may be some tricks to work around that. Thanks David for bringing this up. I think it is an important shortcoming of the current tracepoint support. Marc