Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Stan Shebs <stanshebs@earthlink.net>
To: gdb@sourceware.org
Subject: Re: possible QTFrame enhancement
Date: Wed, 29 Oct 2014 22:18:00 -0000	[thread overview]
Message-ID: <545167A3.9010200@earthlink.net> (raw)
In-Reply-To: <CADPb22TXCk0evwC1BkLpER-tMHCBZQLZ8XXo3LC8vkFhjjLPrg@mail.gmail.com>

On 10/29/14, 12:01 PM, Doug Evans wrote:
> On Thu, Oct 16, 2014 at 4:23 PM, Stan Shebs <stanshebs@earthlink.net> 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


  reply	other threads:[~2014-10-29 22:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-18 21:06 David Taylor
2014-10-16 17:03 ` David Taylor
2014-10-16 21:15   ` Pedro Alves
2014-10-16 23:23     ` Stan Shebs
2014-10-22 18:37       ` David Taylor
2014-10-29 19:01       ` Doug Evans
2014-10-29 22:18         ` Stan Shebs [this message]
2015-02-13 19:50       ` filtering traceframes (was: Re: possible QTFrame enhancement) David Taylor
2015-02-22 16:38         ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=545167A3.9010200@earthlink.net \
    --to=stanshebs@earthlink.net \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox