From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13013 invoked by alias); 29 Oct 2014 22:18:17 -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 12994 invoked by uid 89); 29 Oct 2014 22:18:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: elasmtp-banded.atl.sa.earthlink.net Received: from elasmtp-banded.atl.sa.earthlink.net (HELO elasmtp-banded.atl.sa.earthlink.net) (209.86.89.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Oct 2014 22:18:13 +0000 Received: from [68.104.56.205] (helo=macbook2.local) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XjbZD-0001P8-Nn for gdb@sourceware.org; Wed, 29 Oct 2014 18:18:11 -0400 Message-ID: <545167A3.9010200@earthlink.net> Date: Wed, 29 Oct 2014 22:18:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: gdb@sourceware.org Subject: Re: possible QTFrame enhancement References: <4250.1411074396@usendtaylorx2l> <13378.1413479010@usendtaylorx2l> <5440356E.3080705@redhat.com> <54405367.9030000@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940a0651d2c3e5a3843aa9bf2990aaa89af350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg00128.txt.bz2 On 10/29/14, 12:01 PM, Doug Evans wrote: > On Thu, Oct 16, 2014 at 4:23 PM, Stan Shebs wrote: >> [...] >> I concur. I can't think of many other actual tracepoint users right >> now, so your developer gets lots of influence on how it develops >> further. > > While we're on the subject, now's a good time to mention something > that is on my plate. > > Tracepoints suck at collecting c++ data (e.g., what a pretty-printer > would need). > The canonical solution that occurs to me is to do it in python (allow > one to specify what to collect for particular types). > The compiler knows how c++ classes are laid out, but there is still > some intelligence that goes into knowing or optimizing what to > collect. > Plus one would want (I think) the code to live with the pretty-printer > - easier to maintain. > > These are just ideas for discussion. > I haven't gone too far down this path. > Certainly a stimulating direction for thought! Bytecode compilation is basically a simple-minded expression walker, so it's not too much of a stretch to imagine a modified pretty printer that emits bytecodes to collect what it thinks it will need. It starts to break down a little when the pretty printer has conditionals, because the bytecode compiler has to take both paths and emit bytecodes for each. But it's worthwhile if the printer only needs 4 words of a 100-word object - that's a lot of space you're saving per trace frame. A downside is that display is limited to what the pretty printer asks for, so if you have a suspicious situation where a pointer field looks overwritten by the chars of a string, but the data fields right after the pointer were not collected because the pretty printer doesn't normally display them, the user is out of luck in seeing the rest of the overwrite. So in general we tend to want to over-collect. It would be an interesting and not-too-hard trick to add a user control to broaden the collection bytecodes - tweak every block save to include, say, the 10 bytes above and below the specified block. Stan stan@codesourcery.com