Re: MI: -var-create does not resolve typedefs

[Simon Marchi <simon.marchi@ericsson.com>]

On 2018-07-13 04:19 PM, Martin Richtarsky wrote:
> Hi,
> 
> the result of the -var-create command is documented here [1] as follows:
> 
> 'type'
> 
>     The varobj's type. This is a string representation of the type, as
> would be printed by the GDB CLI.
> 
> However, for a typedef this does not seem to hold:
> 
> $ cat mi.cpp
> #include <string>
> #include <vector>
> 
> typedef std::vector<std::string> StringVec;
> typedef int MyInt;
> 
> int main()
> {
>     size_t a = 0;
>     StringVec sv;
>     MyInt i;
>     return 0;
> }
> 
> $ g++ -g2 mi.cpp
> $ gdb --interpreter=mi a.out
> ...
> 1-var-create - * "a"
> 1^done,name="var1",numchild="0",value="4195792",type="size_t",thread-id="1",has_more="0"
> (gdb)
> 2-var-create - * "sv"
> 2^done,name="var2",numchild="1",value="{...}",type="StringVec",thread-id="1",has_more="0"
> (gdb)
> ptype(a)
> &"ptype(a)\n"
> ~"type = unsigned long\n"
> ^done
> (gdb)
> ptype(sv)
> &"ptype(sv)\n"
> ~"type = class std::vector<std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::allocator<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > > > [with _Tp =
> std::basic_string<char, std::char_traits<char>, std::allocator<char> >,
> _Alloc = std::allocator<std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > >] : protected std::_Vector_base<_Tp, _Alloc> {\n"
> ~"  public:\n"
> 
> 
> Note how ptype resolves the typedef, but -var-create just shows the alias.
> 
> The issue can be solved by a simple patch:
> 
> --- a/gdb/varobj-orig.c
> +++ b/gdb/varobj.c
> @@ -905,7 +905,7 @@ varobj_get_type (struct varobj *var)
>    if (CPLUS_FAKE_CHILD (var) || !var->root->is_valid)
>      return std::string ();
> 
> -  return type_to_string (var->type);
> +  return type_to_string (check_typedef(var->type));
>  }
> 
>  /* Obtain the type of an object variable.  */
> 
> 
> This would also solve the issue I'm having when using MI with a split
> dwarf build and a gold index [2]
> 
> Is this a bug or is the typedef intentionally not resolved?
> 
> [1]
> https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Variable-Objects.html
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23042
> 
> Best regards,
> Martin
> 

Hi Martin,

I think it's on purpose that it gives the original type representation, as used
in the code.  That type is going to end up in the "variables" view of the various
frontends.  The type name as used in the code is more meaningful to the user than
the possibly complex resolved type.

Also, it's always possible for the frontend to ask GDB to resolve the typedef, but
it's not possible to go back.  So resolving the typedef right away would loose some
important information.  If people think it would be useful, it would probably be
possible to add a "resolved_type" field to the -var-create response.  That's not
really what you are after though I believe.

As mentioned in the doc [1], ptype's goal is to resolve typedefs, whereas whatis does
not.  I don't see any reason why -var-create should follow ptype's behavior specifically.

Simon

[1] https://sourceware.org/gdb/onlinedocs/gdb/Symbols.html