From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22328 invoked by alias); 6 Nov 2008 18:19:39 -0000 Received: (qmail 22297 invoked by uid 22791); 6 Nov 2008 18:19:38 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 18:18:48 +0000 Received: (qmail 30173 invoked from network); 6 Nov 2008 18:18:46 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Nov 2008 18:18:46 -0000 From: Vladimir Prus To: Nicholas Mc Guire Subject: Re: Tracepoint enhancements Date: Thu, 06 Nov 2008 18:19:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sources.redhat.com References: <490B630F.8010008@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811062118.42764.vladimir@codesourcery.com> 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 X-SW-Source: 2008-11/txt/msg00063.txt.bz2 On Thursday 06 November 2008 17:38:38 Nicholas Mc Guire wrote: > > > Michael Snyder wrote: > > > > >> One possible change to consider is to merge tracepoint setting into > > >> breakpoint setting. Among other benefits would be a single numbering > > >> scheme for breakpoints and tracepoints, plus we will be able to share > > >> some machinery and make things more consistent. > > we have implemented tp for gdb 6.3-6.6 and it might help to play with it > before redesigning things - in our implementation we did not merge tp and > breakpoints as it makes it quite complicated, i.e. breakpoints allow > multiple breakpoints at the same address - for tp this makes little sense. I don't see any fundamental problem here. > the other issue is that you dont care about call overhead on breakpoints > but you do on tracepoints so you probably dont want to have too much > runtime searching going on for tp. What "runtime searching" do you have in mind? > > ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints > > > > > > > > > Just my personal opinion, I would find that confusing. > > and it would make scripting complicated as well. Why? > > > > > > > It seems useful to maintain a fairly sharp distinction > > > between breakpoints and tracepoints, since their behavior > > > is entirely different from both the implementation and the > > > user's point of view. > > > > > > But I would not plan to make a fuss about it... > > > > I think breakpoints and tracepoints have very lots of common. > > > > First of all, the logic of resolving location specification to addresses > > is, conceptually the same. Right now, breakpoints in constructors and > > template functions work. Tracepoints don't seem to, because the fail > > to use the multi-location breakpoint mechanisms. Tracepoints don't have > > conditions -- which is something we want to fix -- and handling of condition > > is a bit tricky too. Breakpoints in shared libraries work just fine -- > > and tracepoints should work too -- but they don't use pending breakpoints > > mechanisms. > > > > one simple way of handling conditional stuff would be to put it into the > bytecode - you would incure the overhead of calling the stub, What do you mean by "calling the stub". I think tracepoints should work entirely on target without any interaction with gdb. > but that > might actually be more convenient with respect to temporal distortion. The > overhead of tracepoints is quite conciderable and thus conditional > breakpoints (notably in multithreaded apps) need to be placed > "synchronously" to not lead to excessive distortions (alteast our > implementatoin showd a conciderable overhead - but you might find a way to > do better). What do you mean by "synchronously". Note that gdb now can keep breakpoints inserted in the target at all times, so the insertion/removal overhead can be eliminated this way. > > On the interface (MI) level breakpoints and tracepoints are essentially > > the same. Breakpoints allow user, or frontend, to do something at specific > > points of program. That something very well can be printing variables. In > > fact, KDevelop does have "tracing" functionality for breakpoints -- where > > on breakpoint hit, selected variables are printed and execution resumes. > > Tracepoints are exactly the same, except that: > > > > - they are more efficient > > they are actually less efficient on the stub-side as they need to use > bytecode to get hold of compound statements and that is definitly less > efficient on the target than on the host. Ok, "they are more efficient provided expression is small enough". For small expressions, roundtrip to target will take more time than on-target evaluation. > Aside from the current spec > having a few sub-optimal things in it (like static array of registers) > > > - they don't cause frontend to be involved, because to be efficient, > > they are entirely stub-side > > the mechanism is a bit different as you need to handle dynamic memmory > allocation for tp or you would end up with a large blob preallocated - not > an issue for breakpoints. Are you talking about stub side of things. Yes, it's different, but for frontend, it does not matter much how stub implements them. > > So it makes perfect sense to treat tracepoints as specially-optimized versions > > of breakpoints. > > I doubt that - de-facto the code would not share much - atleast in our > implementation this was the case, and I doubt that maintenance wise it > makes any sense to merge the code - notably I would expect that the tp > code would start changing once it goes in mainline and users start playing > with it. I disagree. Experience will tell, I think. - Volodya