MI: -var-create does not resolve typedefs

MI: -var-create does not resolve typedefs

[Martin Richtarsky]

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

-- 
http://www.productive-cpp.com/

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

[Simon Marchi]

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

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

[Martin Richtarsky]

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?

[1]

(gdb) bt
#0  0x00007f2a7ee75aba in __strcmp_sse2_unaligned () from /lib64/libc.so.6
#1  0x00000000006f0ad0 in key_compare (key=0x7ffe2ecfa100, name=0xb25f65b0
"_POSIX2_CHAR_TERM", file=0xbee95e50, line=177) at
/h/sources/gdb-8.1/gdb/macrotab.c:323
#2  0x00000000006f0b41 in macro_tree_compare
(untyped_key1=140729683779840, untyped_key2=3202971264) at
/h/sources/gdb-8.1/gdb/macrotab.c:342
#3  0x000000000098aa81 in splay_tree_splay (sp=0xbddec760,
key=140729683779840) at /h/sources/gdb-8.1/libiberty/splay-tree.c:148
#4  0x000000000098b1b9 in splay_tree_lookup (sp=0xbddec760,
key=140729683779840) at /h/sources/gdb-8.1/libiberty/splay-tree.c:455
#5  0x00000000006f12b3 in find_definition (name=0x44fdd730 "STDIN_FILENO",
file=0xbee956b0, line=211) at /h/sources/gdb-8.1/gdb/macrotab.c:642
#6  0x00000000006f138e in check_for_redefinition (source=0xbee956b0,
line=211, name=0x44fdd730 "STDIN_FILENO", kind=macro_object_like, argc=0,
argv=0x0, replacement=0x7f2a011cf03a "0") at
/h/sources/gdb-8.1/gdb/macrotab.c:693
#7  0x00000000006f1579 in macro_define_object_internal (source=0xbee956b0,
line=211, name=0x44fdd730 "STDIN_FILENO", replacement=0x7f2a011cf03a "0",
kind=macro_ordinary) at /h/sources/gdb-8.1/gdb/macrotab.c:763
#8  0x00000000006f1641 in macro_define_object (source=0xbee956b0,
line=211, name=0x44fdd730 "STDIN_FILENO", replacement=0x7f2a011cf03a "0")
at /h/sources/gdb-8.1/gdb/macrotab.c:788
#9  0x0000000000641945 in parse_macro_definition (file=0xbee956b0,
line=211, body=0x7f2a011cf02d "STDIN_FILENO 0") at
/h/sources/gdb-8.1/gdb/dwarf2read.c:23876
#10 0x0000000000642463 in dwarf_decode_macro_bytes (abfd=0x18e9530,
mac_ptr=0x7f2a0004e6cc "\005\324\001\363\001\002", mac_end=0x7f2a000a8497
"", current_file=0xbee956b0, lh=0x39816c70, section=0x3387f3e0,
section_is_gnu=1, section_is_dwz=0, offset_size=4,
include_hash=0xaa35ef10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24275
#11 0x000000000064285a in dwarf_decode_macro_bytes (abfd=0x18e9530,
mac_ptr=0x7f29fffd2794 "\003\343\001\002\a\314\230\a",
mac_end=0x7f2a000a8497 "", current_file=0xbee956b0, lh=0x39816c70,
section=0x3387f3e0, section_is_gnu=1, section_is_dwz=0, offset_size=4,
include_hash=0xaa35ef10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24398
#12 0x000000000064285a in dwarf_decode_macro_bytes (abfd=0x18e9530,
mac_ptr=0x7f29fffd4782 "\003\215\001/\a", mac_end=0x7f2a000a8497 "",
current_file=0xbea8d530, lh=0x39816c70, section=0x3387f3e0,
section_is_gnu=1, section_is_dwz=0, offset_size=4,
include_hash=0xaa35ef10) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24398
#13 0x0000000000642e03 in dwarf_decode_macros (cu=0xaf6d0f10, offset=8572,
section_is_gnu=1) at /h/sources/gdb-8.1/gdb/dwarf2read.c:24623
#14 0x0000000000623479 in read_file_scope (die=0xaf8f5760, cu=0xaf6d0f10)
at /h/sources/gdb-8.1/gdb/dwarf2read.c:11614
#15 0x0000000000621355 in process_die (die=0xaf8f5760, cu=0xaf6d0f10) at
/h/sources/gdb-8.1/gdb/dwarf2read.c:10622
#16 0x0000000000620be8 in process_full_comp_unit (per_cu=0x49a58350,
pretend_language=language_minimal) at
/h/sources/gdb-8.1/gdb/dwarf2read.c:10396
#17 0x000000000061f9db in process_queue () at
/h/sources/gdb-8.1/gdb/dwarf2read.c:9887
#18 0x0000000000610776 in dw2_do_instantiate_symtab (per_cu=0x49a58350) at
/h/sources/gdb-8.1/gdb/dwarf2read.c:3104
#19 0x0000000000610818 in dw2_instantiate_symtab (per_cu=0x49a58350) at
/h/sources/gdb-8.1/gdb/dwarf2read.c:3125
#20 0x0000000000614254 in dw2_lookup_symbol (objfile=0x334e6740,
block_index=0, name=0x107bba00 "size_t", domain=VAR_DOMAIN) at
/h/sources/gdb-8.1/gdb/dwarf2read.c:4304
#21 0x00000000007b54ae in lookup_symbol_via_quick_fns (objfile=0x334e6740,
block_index=0, name=0x107bba00 "size_t", domain=VAR_DOMAIN) at
/h/sources/gdb-8.1/gdb/symtab.c:2383
#22 0x00000000007b58ba in lookup_symbol_in_objfile (objfile=0x334e6740,
block_index=0, name=0x107bba00 "size_t", domain=VAR_DOMAIN) at
/h/sources/gdb-8.1/gdb/symtab.c:2558
#23 0x00000000007b5aff in lookup_symbol_global_iterator_cb
(objfile=0x334e6740, cb_data=0x7ffe2ecfcce0) at
/h/sources/gdb-8.1/gdb/symtab.c:2641
#24 0x0000000000717ab7 in default_iterate_over_objfiles_in_search_order
(gdbarch=0x14a4f40, cb=0x7b5a7d
<lookup_symbol_global_iterator_cb(objfile*, void*)>,
cb_data=0x7ffe2ecfcce0, current_objfile=0x0) at
/h/sources/gdb-8.1/gdb/objfiles.c:1548
#25 0x000000000069be36 in gdbarch_iterate_over_objfiles_in_search_order
(gdbarch=0x14a4f40, cb=0x7b5a7d
<lookup_symbol_global_iterator_cb(objfile*, void*)>,
cb_data=0x7ffe2ecfcce0, current_objfile=0x0) at
/h/sources/gdb-8.1/gdb/gdbarch.c:4825
#26 0x00000000007b5c44 in lookup_global_symbol (name=0x107bba00 "size_t",
block=0x0, domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/symtab.c:2687
#27 0x00000000005d9ec1 in cp_lookup_bare_symbol (langdef=0xa1b780
<cplus_language_defn>, name=0x107bba00 "size_t", block=0x0,
domain=VAR_DOMAIN, search=1) at /h/sources/gdb-8.1/gdb/cp-namespace.c:204
#28 0x00000000005dae00 in lookup_namespace_scope (langdef=0xa1b780
<cplus_language_defn>, name=0x107bba00 "size_t", block=0x0,
domain=VAR_DOMAIN, scope=0xa0b5ea "", scope_len=0) at
/h/sources/gdb-8.1/gdb/cp-namespace.c:721
#29 0x00000000005daf2f in cp_lookup_symbol_nonlocal (langdef=0xa1b780
<cplus_language_defn>, name=0x107bba00 "size_t", block=0x0,
domain=VAR_DOMAIN) at /h/sources/gdb-8.1/gdb/cp-namespace.c:756
#30 0x00000000007b4c03 in lookup_symbol_aux (name=0x107bba00 "size_t",
match_type=symbol_name_match_type::FULL, block=0x0, domain=VAR_DOMAIN,
language=language_cplus, is_a_field_of_this=0x0) at
/h/sources/gdb-8.1/gdb/symtab.c:2091
#31 0x00000000007b43f8 in lookup_symbol_in_language (name=0x107bba00
"size_t", block=0x0, domain=VAR_DOMAIN, lang=language_cplus,
is_a_field_of_this=0x0) at /h/sources/gdb-8.1/gdb/symtab.c:1887
#32 0x00000000007b4472 in lookup_symbol (name=0x107bba00 "size_t",
block=0x0, domain=VAR_DOMAIN, is_a_field_of_this=0x0) at
/h/sources/gdb-8.1/gdb/symtab.c:1899
#33 0x00000000005dcce5 in replace_typedefs (info=0xa0e925c0,
ret_comp=0xadd93430, finder=0x5b8ded <find_typedef_for_canonicalize(type*,
void*)>, data=0x7ffe2ecfd280) at /h/sources/gdb-8.1/gdb/cp-support.c:431
#34 0x00000000005dcf80 in cp_canonicalize_string_full (string=0x15b2dd0
"size_t", finder=0x5b8ded <find_typedef_for_canonicalize(type*, void*)>,
data=0x7ffe2ecfd280) at /h/sources/gdb-8.1/gdb/cp-support.c:521
#35 0x00000000005b8e5d in print_name_maybe_canonical (name=0x15b2dd0
"size_t", flags=0x7ffe2ecfd280, stream=0x1376300) at
/h/sources/gdb-8.1/gdb/c-typeprint.c:90
#36 0x00000000005bd162 in c_type_print_base_1 (type=0x1794c30,
stream=0x1376300, show=-1, level=0, flags=0x7ffe2ecfd280,
podata=0x7ffe2ecfd250) at /h/sources/gdb-8.1/gdb/c-typeprint.c:1571
#37 0x00000000005b8fa7 in c_print_type_1 (type=0x1794c30,
varstring=0xaa03d3 "", stream=0x1376300, show=-1, level=0,
flags=0x7ffe2ecfd280, podata=0x7ffe2ecfd250) at
/h/sources/gdb-8.1/gdb/c-typeprint.c:126
#38 0x00000000005b9151 in c_print_type (type=0x1794c30, varstring=0xaa03d3
"", stream=0x1376300, show=-1, level=0, flags=0x7ffe2ecfd280) at
/h/sources/gdb-8.1/gdb/c-typeprint.c:172
#39 0x0000000000812919 in whatis_exp (exp=0x1207067 "slow", show=-1) at
/h/sources/gdb-8.1/gdb/typeprint.c:541
#40 0x000000000081297a in whatis_command (exp=0x1207067 "slow",
from_tty=1) at /h/sources/gdb-8.1/gdb/typeprint.c:553
#41 0x0000000000470136 in do_const_cfunc (c=0x13465a0, args=0x1207067
"slow", from_tty=1) at /h/sources/gdb-8.1/gdb/cli/cli-decode.c:106
#


-- 
http://www.productive-cpp.com/

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

[Simon Marchi]

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