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

"Martin Richtarsky" <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <244d2f88027af80aae3812b0597e8c19-EhVcX1dJRwNeRwQRAQsKVxcwfgFLV15YQUBGAEFbWkA3VF0NQVpwH1FRQ15cRioDWllfQ1tUUAlZ-webmailer1@server06.webmailer.hosteurope.de>
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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.