This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: Improved pretty printing for smart pointers


Tom,

creating an iterator is necessary in gdb 7.4.1.

Actually, this is what I tried first:

    def children (self):
        managedValue = self.val['_M_ptr']
        if managedValue == 0:
	    return []
	else:
            return [('Use count', self.val['_M_refcount']['_M_pi']['_M_use_count']),
                    ('Weak count', self.val['_M_refcount']['_M_pi']['_M_weak_count']),
                    ('Managed value', managedValue)]

This implementation obviously conforms to the requirement that the children method must return something iterable. Nevertheless, with that way of 
implementation the graphical debuggers will just show "Error" for the value of a smart pointer, although this pretty printer works fine in gdb:

$1 = std::shared_ptr (usecount 1, weakcount 0) to 0x80640f8 = {Use count = 1, Weak count = 1, Managed value = 0x80640f8}

(In contrast to what I said in a previous mail, gdb does not pretty print the managed value.)

Is this a gdb bug?

Michael


On Friday 26 April 2013 21:55:20 Tom Tromey wrote:
> >>>>> "Jonathan" == Jonathan Wakely <jwakely.gcc@gmail.com> writes:
> Michael> I know that there are ways to dereference a smart pointer on
> Michael> the gdb command line. But when using an IDE (like Eclipse CTD,
> Michael> Qt Creator or kdevelop), the pretty printer, in its current
> Michael> state, is in the way: The variable view of the debugger will
> Michael> show a message like
> 
> Michael> "std::shared_ptr (count 1, weak 0) 0x61e1a8"
> 
> Jonathan> This sounds like a deficiency of those debugger GUIs.
> 
> The fundamental problem is probably in gdb.
> 
> The current SharedPointerPrinter just renders the pointer value into a
> string:
> 
>         return '%s (%s) %s' % (self.typename, state, self.val['_M_ptr'])
> 
> But this strips any identifying info that the MI client might use to
> dereference this.  It isn't obviously a pointer and any type information
> isn't present in a usable (by the MI client) form.
> 
> Having 'children' would solve this.
> 
> 
> There's another issue in gdb where if a printer has children, then the
> to_string result is replace with "{...}" for MI.  This means that
> returning the various counts in to_string but the pointer in children
> will make the counts invisible to the MI client :(
> 
> There's a patch for this pending... maybe we should put it in.
> 
> 
> I think the downside of moving all the fields to 'children' is just that
> the CLI will be more verbose.  I'm not sure this is so bad.  What this
> would mean for the patch is simplifying the to_string method to just
> show the type name; then I think the output would be like:
> 
> $1 = std::shared_ptr = {Use count = 1, Weak count = 2, Managed value =
> 0x605028}
> 
> 
> Maybe there is some other gdb change that would make this better.
> I haven't thought of one but I'm open to suggestions.
> 
> Jonathan> Would it work if we changed the output to this?
> Jonathan> $1 = std::shared_ptr<int> (usecount 1, weakcount 2) { 0x605028 }
> Jonathan> $2 = std::weak_ptr<int> (usecount 1, weakcount 2) { 0x605028 }
> Jonathan> $4 = std::unique_ptr<double> { 0x605040 }
> 
> This runs into the MI issue.
> 
> 
> In the patch itself, creating an iterator is overkill.  That approach is
> mostly useful for containers, not something with a fixed number of
> fields.  For fixed fields, just return a tuple or a list from
> 'children'.
> 
> Tom


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