From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26354 invoked by alias); 6 Nov 2008 13:23:50 -0000 Received: (qmail 26318 invoked by uid 22791); 6 Nov 2008 13:23:48 -0000 X-Spam-Check-By: sourceware.org Received: from qw-out-1920.google.com (HELO qw-out-1920.google.com) (74.125.92.148) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 13:22:45 +0000 Received: by qw-out-1920.google.com with SMTP id 4so349726qwk.24 for ; Thu, 06 Nov 2008 05:22:42 -0800 (PST) Received: by 10.214.148.20 with SMTP id v20mr2161710qad.71.1225977762811; Thu, 06 Nov 2008 05:22:42 -0800 (PST) Received: by 10.214.80.15 with HTTP; Thu, 6 Nov 2008 05:22:42 -0800 (PST) Message-ID: Date: Thu, 06 Nov 2008 13:23:00 -0000 From: "=?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?=" To: "Joel Brobecker" Subject: Re: Heute Secore: Unsafe documentation? Cc: gdb@sourceware.org In-Reply-To: <20081106132037.GA3760@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20081106132037.GA3760@adacore.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/msg00054.txt.bz2 MjAwOC8xMS82IEpvZWwgQnJvYmVja2VyIDxicm9iZWNrZXJAYWRhY29yZS5j b20+Ogo+PiBDb3VsZCBzb21lb25lIG1hbmFnaW5nIEdEQidzIHdlYnNpdGUg Y29udGFjdCB3aXRoIEhldXRlIFNlY3VyZSBhYm91dAo+PiB0aGlzIHdhcm5p bmc6Cj4+Cj4+IGh0dHA6Ly9oYXV0ZXNlY3VyZS5jb20vb3BlcmFfc2l0ZWlu Zm8uYXNweD9pPWh0dHA6Ly9zb3VyY2V3YXJlLm9yZy9nZGIvY3VycmVudC9v bmxpbmVkb2NzL2dkYl90b2MuaHRtbAo+Cj4gQXMgZmFyIGFzIEkgYW0gY29u Y2VybmVkLCB0aGlzIHNpdGUgaXMganVuay4gTm90IGJlY2F1c2UgaXQgcHJv dmlkZXMKPiBiYWQgd2FybmluZ3MsIGJ1dCBiZWNhdXNlIHNldmVyYWwgb2Yg dXMgaGF2ZSB0cmllZCB0byBkZXRlcm1pbmUgd2hhdAo+IGl0IHdhcyB0aGF0 IHdhcyAiYmFkIiBpbiBvcmRlciB0byBmaXggaXQsIHRvIG5vIGF2YWlsLiBJ ZiB5b3UgY2FuIGZpbmQKPiB3aGF0IGl0IGlzIHRoYXQgdGhleSBhcmUgd2Fy bmluZyB5b3UgYWdhaW5zdCwgdGhlbiB3ZSdsbCB0cnkgdG8gZml4IGl0Lgo+ IFdlIGV2ZW4gdHJpZWQgdG8gZ28gdGhyb3VnaCB0aGUgcHJvY2VkdXJlIG9m IGdldHRpbmcgdGhlIHNpdGUKPiByZS1ldmFsdWF0ZWQsIHNpbmNlIHRoaXMg YXBwZWFycyB0byBiZSB0aGUgb25seSB0aGluZyB0aGF0IHdlIGNhbiBkbwo+ IGZyb20gdGhlIHBhZ2UgeW91IHJlZmVyZW5jZSwgYXNraW5nIGluIHRoZSBu b3RlcyB0byBjb250YWN0IHVzIHdpdGgKPiBtb3JlIGluZm8gaWYgdGhlIHBh Z2UgZGlkbid0IHBhc3MuIE5vdGhpbmcgaGFwcGVuZWQuCgpTaGFtZSBvbiB0 aGVtIHRoZW4uIFBsdXMgb24gT3BlcmEgZm9yIHVzaW5nIHRoZWlyIGRhdGFi YXNlIDp8CgpUaGFuayB5b3UgZm9yIGluZm8uCgotLSAKUmFmYcWCIE1pxYJl Y2tpCg== >From gdb-return-33290-listarch-gdb=sources.redhat.com@sourceware.org Thu Nov 06 14:44:52 2008 Return-Path: Delivered-To: listarch-gdb@sources.redhat.com Received: (qmail 21287 invoked by alias); 6 Nov 2008 14:44:50 -0000 Received: (qmail 21196 invoked by uid 22791); 6 Nov 2008 14:44:49 -0000 X-Spam-Check-By: sourceware.org Received: from Unknown (HELO mail.hofr.at) (194.112.174.227) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 14:43:59 +0000 Date: Thu, 06 Nov 2008 14:44:00 -0000 From: Nicholas Mc Guire To: Vladimir Prus cc: gdb@sources.redhat.com Subject: Re: Tracepoint enhancements In-Reply-To: Message-ID: References: <490B630F.8010008@codesourcery.com> <490B6CEF.2000003@vmware.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Delivered-To: mailing list gdb@sourceware.org X-SW-Source: 2008-11/txt/msg00055.txt.bz2 Content-length: 4607 > 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. 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. You might want to give it a look at: 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. > > > > 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, 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). > 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. 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. > > 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. > In order for breakpoint to be optimized like this, the list > of commands for that breakpoints should only use a limited set of commands, > and end with 'continue' > > > One more thing, only vaguely related... > > > > I've thought that if we had the ability to attach an expression > > (in pcode such as we use for tracepoints) to a conditional breakpoint, > > we could have the conditional evaluation be done on the target > > rather than by gdb, which would be a big performance win for > > conditional breakpoints or watchpoints. > > Yes. We want conditional tracepoints, and the condition would have to be evaluated > on the target. And if breakpoints and tracepoints are unified, both breakpoints and > tracepoints will benefit. > I dont see any benefit for the breakpoints by merging in tracepoints. hofrat