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

[Pedro Alves <pedro@palves.net>]

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.