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

On 2018-09-07 15:50, Martin Richtarsky wrote:
> Simon Marchi schrieb:
>> 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
> 
> Hi Simon,
> 
> thanks for the response. I can understand why that behavior makes 
> sense.
> 
> However, I don't understand the implementation in gdb. A bit of
> background: I have a rather large application (many TUs) that is built
> with -gsplit-dwarf. When running a whatis on e.g. a size_t variable, it 
> is
> very slow. gdb is stuck in such a callstack: [1]
> 
> So replace_typedefs() is called although typedefs are not supposed to 
> be
> resolved.
> 
> Basically the type is available already in c_type_print_base_1() before
> the call to print_name_maybe_canonical() and even earlier.
> 
> (gdb) p type->main_type->name
> $9 = 0x15b2dd0 "size_t"
> 
> Would it possible to change this? It would speed up debugging 
> interaction
> tremendously. Or is the typedef resolution necessary for something I'm
> missing?

By any chance, is the application you debug free/open, so I could build 
it?  It's quite difficult to reproduce performance problems 
synthetically, so if I was able to debug the same thing as you, we could 
compare apples to apples.  Otherwise, if you are able to reproduce it 
with another large free software project, it could work too.

Thanks,

Simon