Re: [PATCH 4/4] gdb: make internalvar use a variant

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2022-03-16 09:26, Pedro Alves wrote:
> On 2022-03-16 02:06, Simon Marchi wrote:
> 
>> With std:
>>
>>
>> $1 = {
>>   next = 0x60600000ff20,
>>   name = 0x602000085350 "salut",
>>   v = std::variant<internalvar_void, internalvar_value, internalvar_make_value, internalvar_function, internalvar_integer, internalvar_string> [index 0] = {{<No data fields>}}
>> }
>>
>>> AFAICT from variant.cpp source file, the variant storage is an untyped buffer:
>>>
>>>     enum { data_align = detail::typelist_max_alignof< variant_types >::value };
>>>
>>>     using aligned_storage_t = typename std::aligned_storage< data_size, data_align >::type;
>>>     aligned_storage_t data;
>>>
>>> so I guess printing a nonstd::variant results in pretty opaque output.  We'd need a pretty
>>> printer to fix this.  Or maybe we just assume that people developing/debugging GDB build
>>> it against a C++17 or higher compiler?  (Not sure that's a great assumption.)
>>
>> Do you know off-hand if the std::variant pretty printer is supposed to
>> show the active data field?
> 
> I think that's already shown in your "with std" output above.  It just happens that
> internalvar_void has no data fields.  E.g., with:
> $ cat ./variant.cc 
> 
> #include <string>
> #include <variant>
> 
> int
> main ()
> {
>   std::variant<std::string, int> v;
> 
>   v = "hello";
>   v = 1;
> 
>   return 0;
> }
> 
> Stepping through the assignment lines, I get:
> 
>  (gdb) p v
>  $1 = std::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> [index 0] = {"hello"}
>  (gdb) n
>  (gdb) p v
>  $2 = std::variant<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, int> [index 1] = {1}
> 
> I wouldn't say this is super ideal output, as it forces you to count the types to
> know what index 0 and 1 are, though, as well as puts the data far off to the right.

Oh, yeah, thanks for pointing that out, seems obvious now.  I was
assigning an integer, so I thought I was printing an integer
internalval, but no.

Simon