RE: [RFC] Change how value is shown for varobjs of type vector.

[Marc Khouzam <marc.khouzam@ericsson.com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Joel Brobecker
> Sent: Sunday, October 14, 2012 1:25 PM
> To: Andrew Burgess
> Cc: gdb-patches@sourceware.org
> Subject: Re: [RFC] Change how value is shown for varobjs of 
> type vector.
> 
> > I have a patch (below) that changes the value field from the current
> > "[8]" to "{ 0, 0, 0, 0, 0, 0, 0, 0 }".  The varobj still has 8
> > children, and the top level varobj is still not editable, 
> you have to
> > edit through the children.
> 
> I personally do not have a strong objection to this change, but I have
> to admit that I am not particularly fond of the idea. I think that
> this issue should be handled at the front-end level (Eg. Eclipse),
> and in a manor that is general to all arrays. One possible suggestion
> would be to have the IDE detect small arrays of integrals, and in
> that case display them in a more convenient way right away. But
> perhaps it isn't easy, in which case maybe a change in GDB would make
> better sense. I just don't like it because it breaks a little bit
> the consistency of the value field.

I have to admit that Eclipse does not explicitly handle the case
of the vector_size __attribute__.  Whatever GDB returns to
-var-create is shown directly.  So, currently, we'll show [8] as
the value.  However, showing { 0, 0, 0, 0, 0, 0, 0, 0 } would not
match our standard behavior.  For arrays, we show the address
of the array as the unexpanded value, and then show the content 
in a 'details pane' when the user explicitly selects that array.  
We get the content that you are looking for using
  -data-evaluate-expression vector
  ^done,value="{0, 0, 0, 0, 0, 0, 0, 0}"

So, I agree with Joel that it would be better to let the front-end
deal with this situation (although this is not my call to make :) )

Although I haven't tried, I believe we can figure out this case
should be handled like the array case by improving Eclipse's type
parser to handle the vector_size __attribute__.

Thanks

Marc