Re: Language of registers

[Daniel Jacobowitz <drow@false.org>]

On Tue, Nov 28, 2006 at 08:04:11PM +0300, Vladimir Prus wrote:
> First of all, varobjs don't know anything about Ada. Further, unlike CLI, 
> varobj don't have any language-specific formatting -- it's just tree of 
> values. 

Sure there is.  There isn't for structs or arrays, but I presume it
still calls the language specific routines for formatting e.g.
integers.  And types.

(gdb) set language ada
(gdb) interpreter-exec mi "-var-create - * $xmm0"   
^done,name="var1",numchild="7",type="builtin_type_vec128i"
(gdb) 
(gdb) interpreter-exec mi "-var-list-children var1"
^done,numchild="7",children=[child={name="var1.v4_float",exp="v4_float",numchild="4",type="array (...) of float"},child={name="var1.v2_double",exp="v2_double",numchild="2",type="array (...) of double"},child={name="var1.v16_int8",exp="v16_int8",numchild="16",type="array (...) of int8_t"},child={name="var1.v8_int16",exp="v8_int16",numchild="8",type="array (...) of int16_t"},child={name="var1.v4_int32",exp="v4_int32",numchild="4",type="array (...) of int32_t"},child={name="var1.v2_int64",exp="v2_int64",numchild="2",type="array (...) of int64_t"},child={name="var1.uint128",exp="uint128",numchild="0",type="int128_t"}]
(gdb) 
(gdb) interpreter-exec mi "-var-list-children --all-values
var1.v16_int8"
^done,numchild="16",children=[child={name="var1.v16_int8.0",exp="0",numchild="0",value="0",type="int8_t"},...

Try that in C, you'll get value="0 '\\0'" instead of value="0".

OK, char is a fairly silly example of the point, but if you don't limit
it to just register variables you can come up with other language
specific differences.  The language specific value and type printers
are used.

> > I'd suggest that we don't need the fake "public" child for things of
> > struct/union (as opposed to class) type that are 100% public.  We can't
> > reliably detect struct vs class because debug info is often lacking the
> > distinction, but union is easy.  I don't know if this might break some
> > MI frontend though.  But the "public" child isn't even documented.
> 
> You're right that such a change will make my patch unnecessary. I'm not sure 
> what frontend authors say, though. Personally, I don't see any reason why a 
> debugger should group members by accessibility, and KDevelop just hides those 
> pseudo-fields. Eclipse, on the other hand, shows them, but probably will work 
> just fine without.
> 
> The change does not seem very complex, but the changes to testcases will be 
> huge, so I'd like to check. Does everybody agree with removing "public" 
> pseudo-field from structures that have only public fields?

We can't tell reliably if something was declared as "struct" or "class"
in the source, but I think unions default to public, don't they?

-- 
Daniel Jacobowitz
CodeSourcery