feature idea: type nicknames

feature idea: type nicknames

[Roland McGrath]

So, a thing I'm looking at all day and all night today looks like this:

21.9                        y     0x0000000000437a0e in talker<elfutils::dwarf_edit, elfutils::dwarf_output>::mismatch(std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > > >, std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > > > const&, std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_output, elfutils::dwarf_output::value_wrapper> > >, std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_output, elfutils::dwarf_output::value_wrapper> > > const&)

(At the moment, I'm just talking about the long hoary type names.
But, yes, that is location 9 of breakpoint 21.  Breakpoint 5 has 15 locations.)

So, to start with, some of that is STL internals hooey that I, poor lowly
programmer, am not responsible for.  This here:

std::_Rb_tree_const_iterator<std::pair<int const, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > > >

appears in *my* code nowhere in a form longer than:

std::map<int, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > >::const_iterator

Now that is not so short, but let's stick with the STL part for the moment:

std::map<a, b>::const_iterator

Now leaving aside how ugly a and b are to print, that is pretty nice.
What makes sense to me is that the STL pretty printer module can also
have "type name pretty-printers".  This would let them match
std::_Rb_tree_const_iterator<...> and pick apart the ... to discern
what proper std::some<...>::const_iterator to call it.


Now let's consider the same thing for my own program.  Say I don't
even know Python, but I'm all template-happy with my C++ and I really
do think I know what I'm trying to do, but my eyes are bleeding.

(gdb) whatis it
type = elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator
(gdb) callthat dieptr
dieptr = elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator
(gdb) p &it
$27 = (dieptr *) 0x1234567
(gdb) thank you, oh thank you
Labor creates all wealth.
(gdb)

For extra points:

(gdb) whatis it
type = const elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator &
(gdb) callthat const dieptr &
dieptr = elfutils::dwarf::skipping_wrapper<elfutils::dwarf::debug_info_entry::raw_attributes_type, elfutils::dwarf::attribute, elfutils::dwarf::attribute, elfutils::dwarf::skip_sibling>::const_iterator
(gdb) whatis it
type = const dieptr &
(gdb)

I imagine it might actually be called "set print typename dieptr = it"
or something.

This command idea dovetails with what I think library pretty printers
like STL's should implement somehow anyway.  

But the "type-only convenience" variables idea could be another
approach for this casual kind of use:

(gdb) set $dieptr = typeof(it)
(gdb) p &it
$227 = ($dieptr *) 0x1234567
(gdb)

However, having only $names by nature might not be the thing people
like the most.

Getting back to the basic "type-name pretty-printing": I think it
would make sense to have some heuristic defaults along with any
library-specific hooks.  Like maybe "shortest public name" among
typedefs all resolving to the same thing, etc.


Thanks,
Roland

Re: feature idea: type nicknames

[Tom Tromey]

>>>>> "Roland" == Roland McGrath <roland@redhat.com> writes:

[...]
Roland> appears in *my* code nowhere in a form longer than:

Roland> std::map<int, elfutils::dwarf_data::attr_value<elfutils::dwarf_edit, elfutils::dwarf_data::value<elfutils::dwarf_edit> > >::const_iterator

We looked into this particular sub-problem a little.  Our idea was
that it would be nice if "ptype x" showed exactly what the user wrote
in the declaration of "x".

In the end it seems that GCC usually emits the verbose forms.  I filed
a gcc bug report about this; but it isn't completely clear that this
is what we actually want (see last comment):

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37590

Another idea would be to suppress printing of defaulted template
parameters by default.  I don't think we've researched that yet.  (I
assume we'll get into the usual problems: DWARF still can't represent
everything, and anyway even if it could, GCC doesn't emit it :-)

Roland> What makes sense to me is that the STL pretty printer module can also
Roland> have "type name pretty-printers".

Interesting idea.  Maybe it is time to resurrect the currently-defunct
type-printing task.

Tom

Re: feature idea: type nicknames

[Roland McGrath]

> We looked into this particular sub-problem a little.  Our idea was
> that it would be nice if "ptype x" showed exactly what the user wrote
> in the declaration of "x".

Yes, that's the ideal default.  The "shortest way to say it" heuristic is a
"better than nothing" idea for the default given limitations on what gdb
can/does figure out from the DWARF.  (I think the manually user-added
nicknames would be nice too.  Sometimes what I wrote in the source is a bit
long to use a hundred times in a long debugging session.)

> In the end it seems that GCC usually emits the verbose forms.  I filed
> a gcc bug report about this; but it isn't completely clear that this
> is what we actually want (see last comment):

I don't really follow what that comment says, but I concur that this
qualifies as "isn't completely clear". :-)

> Another idea would be to suppress printing of defaulted template
> parameters by default.  I don't think we've researched that yet.  

Yes, I think that is obviously desireable.

> (I assume we'll get into the usual problems: DWARF still can't represent
> everything, and anyway even if it could, GCC doesn't emit it :-)

Got to push on the stack from one end or the other to make it move.


Thanks,
Roland