Re: [PATCH] Add real-type to MI output

[Simon Marchi <simon dot marchi at ericsson dot com>]

Hi Vladimir,

Thanks for the comments.

On 02/17/2015 01:26 AM, Vladimir Prus wrote:
> I don't think it's the best way to accomplish the desired effect. Instead, you can invoke -var-list-children with the
> --simple-values option. Then, you'd have either "{...}" as value or the pointer value reported directly by GDB. You'd
> also potentially save a roundtrip to get the value.

Oh, I didn't know about --simple-values (or --all-values). Actually, I think only --all-values prints the "{...}".
Thanks for pointing that out.

So right now, CDT requests the list of children without the values, and then requests only the values of the children
that are visible in the variable view, using -var-evaluate-expression. If we used -var-list-children with --simple-values
or --all-values, we would get all the values in one shot, which is I think what we want to avoid (for big structures and/or
slow targets).

However, the solution might be even simpler. If CDT asked GDB the value (-var-evaluate-expression) of all visible children,
regardless of their types, we wouldn't have this problem to begin with. We would always get the right thing. For arrays and
structures, GDB would return "{...}". For the IntPointer variable, it will return the numerical value. We would send a few
more -var-evaluate-expression, but not that much more, since it's still limited by what the variables view displays. I just
tried it, it seems to work fine...

The only thing CDT doesn't know now is that the IntPointer value is editable. I think it would have to issue a
-var-show-attributes to know that. Do you know why we don't have this information right away in the -var-list-children
output?

> Actually, just did something similar internally - it was a bit tricky to get that in Eclipse DSF, and I had a special
> case, but still seems better than expanding the interface with GDB?

You are right, it's much better to work with existing interfaces.

> Another case, what do you do with std::shared_ptr<Foo> or boost::shared_ptr<Foo>? Both would be naturally shown
> similarly to Foo* - where you see the value immediately and can expand the object - and GDB would be able to do
> so with a suitable pretty-printer, but if a frontend is supposed to parse types, that won't work.

IIUC, if a pretty printer exists for a type, CDT always asks GDB for the value, regardless of the type. Since a shared_ptr's
value comes from a pretty printer, I think it would've worked.

>> About the naming:
>>
>> Right now, the term "real type" means the run-time type, in the sense of
>> looking at an object through a pointer to a virtual class. However, it's
>> not part of any API or significant user interface (only one I found is
>> in the output of "whatis"), so it's not set in stone. If I could
>> choose, I would give "real type" the meaning of the current patch, and
>> call the other one the "runtime type". Or is there already a term for it?
>> What do you think?
>>
>> Other ideas that went through my mind, if "real type" is not an option:
>>
>>   * canonical-type
>>   * resolved-type
>>   * underlying-type
>>
>> Another issue. It doesn't affect us, but I wasn't sure about this case:
>>
>>    struct blah {
>>      ...
>>    };
>>    typedef struct blah blah_t;
>>
>>    blah_t *b;
>>
>> What should real-type return for b? Right now it returns "blah_t *", but
>> should it return "struct blah *" instead?
> 
> If if were to return 'struct blah *', what would frontend do? Try to parse the type?
> Trying to parse 'int *' is already a tad risky - i.e. do you handle all possible syntax,
> like:
> 
> 	std::vector<My::Namespace::C> *
> 
> Quite some time ago we discussed the idea of exposing GDB type system to a frontend:
> 
> 	https://www.sourceware.org/ml/gdb/2006-04/msg00016.html
> 
> However, that will not be easy, and so far, frontends did not need entire type.

CDT already does its fair share of GDB type parsing, but I agree that it's an easy source of headache. Then less CDT needs to do
the better.

Simon