Re: Language of registers

[Vladimir Prus <ghost@cs.msu.su>]

Nick Roberts wrote:

> 
>> At the moment, MI varobj assume that register values have a language. As
>> result, if you try to look at values of $xmm1 in a C++ program, you'll
>> find that this registers has a 'public' field -- which is not reasonable.
> 
>> The attached patch causes MI to always force the C language for register
>> values, so no special processing takes place. OK?
> 
> Experimenting with register names as variable objects:
> 
> With C:
> 
>   -var-create - * $xmm1
>   ^done,name="var1",numchild="7",type="builtin_type_vec128i"
>   (gdb)
>   -var-list-children var1
>   &"Attempt to take address of value not located in memory.\n"
>   ^error,msg="Attempt to take address of value not located in memory."
> 
> 
> With C++
> 
>   -var-create - * $xmm1
>   ^done,name="var1",numchild="1",type="builtin_type_vec128i"
>   (gdb)
>   -var-list-children var1
>   Segmentation fault (core dumped)

What gdb is this? Both work fine for me with mainline.

> but there are already MI commands for registers.  Notably
> 
> -data-list-register-values
> 
> and
> 
> -data-list-changed-registers which is a bit like var-update.
> 
> 
> What advantage do variable objects offer for register names?

To begin with -- consistenly. There is no fundamental difference between
ordinary values and registers. The frontend knows how to display the
hierarchy of variable objects, and there's no need to force the frontend to
have additional logic for register. Note that Eclipse, for example, does
create variable objects for all registers at the moment.

The second advantage is that -data-list-register-values has no hierarchy at
all. If you try 

  -data-list-register-values xmm1

then gdb print print half-screen of output that should be specially parsed
and displayed. When using variable objects, the frontend already has the
parsing/display code.

- Volodya






> 
>