This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: possible QTFrame enhancement


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]