Re: Language of registers

Re: Language of registers

[Nick Roberts]

> > What advantage do variable objects offer for register names?

> To begin with -- consistenly. There is no fundamental difference between
> ordinary values and registers.

Is that true?  Is the logic not simpler for registers?  No need to use
GDB's notion of values, check whether they've been fetched etc.

>                                 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.

What hierarchy are you talking about?  Would a variable object for a register
have children?

> 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. 

I think that's because your syntax is wrong:

-data-list-register-names 33
^done,register-names=["xmm1"]
(gdb)
-data-list-register-values x 33
^done,register-values=[{number="33",value="{v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint128 = 0x00000000000000000000000000000000}"}]


>                When using variable objects, the frontend already has the
> parsing/display code.

What would your variable object print for xmm1?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Language of registers

[Daniel Jacobowitz]

On Thu, Dec 07, 2006 at 10:49:57AM +1300, Nick Roberts wrote:
> >                When using variable objects, the frontend already has the
> > parsing/display code.
> 
> What would your variable object print for xmm1?

Instead of a big string, it could have a triangle to expand xmm1,
display it as uint32_t[4] and uint8_t[16] on different lines... just
like we do for structures, right?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Language of registers

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Thu, Dec 07, 2006 at 10:49:57AM +1300, Nick Roberts wrote:
 > > >                When using variable objects, the frontend already has the
 > > > parsing/display code.
 > > 
 > > What would your variable object print for xmm1?
 > 
 > Instead of a big string, it could have a triangle to expand xmm1,
 > display it as uint32_t[4] and uint8_t[16] on different lines... just
 > like we do for structures, right?

OK, I see now.  I'm not familiar with these large registers (just the ones that
hold one value!).  I was just thinking that maybe variable objects are `heavy
armour' for registers and that it might be simpler to change the output format
of the -data-list-* commands instead.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Language of registers

[Daniel Jacobowitz]

On Thu, Dec 07, 2006 at 11:23:05AM +1300, Nick Roberts wrote:
> OK, I see now.  I'm not familiar with these large registers (just the ones that
> hold one value!).  I was just thinking that maybe variable objects are `heavy
> armour' for registers and that it might be simpler to change the output format
> of the -data-list-* commands instead.

Right.  I think it depends what the front end is going to do with the
data.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Language of registers

[Nick Roberts]

> 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)

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?


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Language of registers

[Vladimir Prus]

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






> 
> 

Re: Language of registers

[Eli Zaretskii]

> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Mon, 27 Nov 2006 09:32:09 +0300
> > 
> > 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.

It would be nice to have these explanation in the manual...

Thanks.

Language of registers

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]


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?

- Volodya

	* varobj.c (varobj_create): For register values,
	always use C as the language.

[-- Attachment #2: c_registers__gdb_mainline.diff --]
[-- Type: text/x-diff, Size: 794 bytes --]

=== gdb/varobj.c
==================================================================
--- gdb/varobj.c	(/mirrors/gdb_mainline)	(revision 2298)
+++ gdb/varobj.c	(/patches/gdb/c_registers/gdb_mainline)	(revision 2298)
@@ -518,7 +518,15 @@
       var->type = value_type (var->value);
 
       /* Set language info */
-      lang = variable_language (var);
+      if (VALUE_REGNUM (var->value) != -1)
+	/* For register values, we don't want any language
+	   specific processing, so use the less specialized
+	   language.  Otherwise, in C++ programs registers likes
+	   xmm1 will feature 'public' children, that makes no
+	   sense for registers.  */
+	lang = vlang_c;
+      else
+	lang = variable_language (var);
       var->root->lang = languages[lang];
 
       /* Set ourselves as our root */

Re: Language of registers

[Daniel Jacobowitz]

On Sat, Nov 25, 2006 at 02:21:43PM +0300, Vladimir Prus 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.

I'm unsure.  Maybe it's actually right the way it is?  All of GDB's
other forms of output adjust with the current language.  For instance,
in the CLI:

(gdb) set lang ada
(gdb) p $xmm1
$4 = (v4_float => (0 => 0.0, 0.0, 0.0, 0.0), v2_double => (0 => 0.0, 
    0.0), v16_int8 => (0 => 0 <repeats 16 times>), v8_int16 => (0 => 
    0, 0, 0, 0, 0, 0, 0, 0), v4_int32 => (0 => 0, 0, 0, 0), 
  v2_int64 => (0 => 0, 0), 
  uint128 => 0x00000000000000000000000000000000)
(gdb) ptype $xmm1
type = record (?) is
    case ? is
        when ? =>
            v4_float: array (0 .. 3) of float;
        when ? =>
            v2_double: array (0 .. 1) of double;
        when ? =>
            v16_int8: array (0 .. 15) of int8_t;
        when ? =>
            v8_int16: array (0 .. 7) of int16_t;
        when ? =>
            v4_int32: array (0 .. 3) of int32_t;
        when ? =>
            v2_int64: array (0 .. 1) of int64_t;
        when ? =>
            uint128: int128_t;
    end case;
end record

And that might be more comfortable for an Ada programmer.

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.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Language of registers

[Vladimir Prus]

On Monday 27 November 2006 17:03, Daniel Jacobowitz wrote:
> On Sat, Nov 25, 2006 at 02:21:43PM +0300, Vladimir Prus 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.
>
> I'm unsure.  Maybe it's actually right the way it is?  All of GDB's
> other forms of output adjust with the current language.  For instance,
> in the CLI:
>
> (gdb) set lang ada
> (gdb) p $xmm1
> $4 = (v4_float => (0 => 0.0, 0.0, 0.0, 0.0), 

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. 

Language-specific code in varobj.c basically does two things:

	- Add those public child for C++
	- Escapes "." for Java (to avoid conflict with "." used in between
	varobj levels themself)

Neither seems reasonable to do for registers.

> 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?

- Volodya


Does everybody agree with removing 'pu

Re: Language of registers

[Daniel Jacobowitz]

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

Re: Language of registers

[Vladimir Prus]

Daniel Jacobowitz wrote:

> 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"},

What I said ("varobjs don't know anything about Ada") is still true,
though ;-) 

There are two completely independent languages. One language is that used to
values and types -- the one changed by "set language". The type output
above comes from "type_print", that just calls LA_PRINT_TYPE, which is just
wrapper over current_language->la_print_type.

On the other hand, varobj->root->lang is internal to varobj.c -- it selects
which of language specific function inside varobj.c itself are called
later.

>> 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?

The *default* to public, but you can have private members in a union.

- Volodya

 

Re: Language of registers

[Daniel Jacobowitz]

On Tue, Nov 28, 2006 at 09:07:52PM +0300, Vladimir Prus wrote:
> What I said ("varobjs don't know anything about Ada") is still true,
> though ;-) 
> 
> There are two completely independent languages. One language is that used to
> values and types -- the one changed by "set language". The type output
> above comes from "type_print", that just calls LA_PRINT_TYPE, which is just
> wrapper over current_language->la_print_type.
> 
> On the other hand, varobj->root->lang is internal to varobj.c -- it selects
> which of language specific function inside varobj.c itself are called
> later.

I don't think that's accurate.  They're not independent.
var->root->lang is set from var->root->exp->language_defn, which is
captured from the global current language when the expression is
parsed.

Having -var-create do something magically different for registers is
strange and confusing.  Maybe, if the patch to automatically create
varobjs for registers goes in, that new command should always use
language_c?

> >> 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?
> 
> The *default* to public, but you can have private members in a union.

That's what I meant.  We can see "oh, this is a union" -> "its default
is public".  We don't know for sure if a source construct was "struct"
(public by default) or "class", though.  But it sounds like we can't
remove the public child now anyway.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Language of registers

[Jim Ingham]

The way I dealt with this for Xcode was to have gdb automatically  
"turn out" all varobj's that have only public fields.  I actually  
added a flag to do this for all the fake children regardless of  
protection type, since some people got really ticked off at them,  
though other people liked them...

So for:

$ cat main.cpp
struct foo
{
   int first;
   int second;
};

   int main ()
{
   struct foo * mine = new foo();

   mine->first = 5;
   mine->second = 10;

   return 0;
}
$ g++ -g -O0 main.cpp
$ gdb a.out
...
(gdb) break main
Breakpoint 1 at 0x1ef8: file main.cpp, line 9.
(gdb) run
Starting program: /private/tmp/a.out
Reading symbols for shared libraries . done

Breakpoint 1, main () at main.cpp:9
9         struct foo * mine = new foo();
(gdb) n
11        mine->first = 5;
(gdb) n
12        mine->second = 10;
(gdb) n
14        return 0;
(gdb) set interpreter mi1
-var-create - * mine
^done,name="var1",numchild="1",type="foo  
*",typecode 
= 
"PTR 
",dynamic_type 
= 
"",in_scope 
="true",block_start_addr="0x00001ef2",block_end_addr="0x00001f2e"}
(gdb)
-var-list-children var1
^ 
done 
,numchild 
= 
"2 
",children 
= 
[child 
= 
{name 
= 
"var1 
.public 
.first 
",exp 
= 
"first 
",numchild 
= 
"0 
",type 
= 
"int 
",typecode 
= 
"INT 
",dynamic_type 
= 
""},child 
= 
{name 
= 
"var1 
.public 
.second 
",exp="second",numchild="0",type="int",typecode="INT",dynamic_type=""}]}

The one little quirk with this is that the "numchild" field in the  
parent object might not be accurate.  But it turned out at least Xcode  
didn't really use that anyway, it just iterated over whatever it got  
from -var-list-children.

In the long run it might be a good idea to rip the fake children out  
altogether.  I liked them when Keith was first doing this stuff, but  
they don't seem all that popular.  Anyway, just expanding them  
automatically was a pretty simple and non-intrusive fix, and from the  
UI standpoint pretty much solves whatever problems folks were having  
with the fake children...

Jim


On Dec 1, 2006, at 6:32 AM, Daniel Jacobowitz wrote:

>
>>>> 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?
>>
>> The *default* to public, but you can have private members in a union.
>
> That's what I meant.  We can see "oh, this is a union" -> "its default
> is public".  We don't know for sure if a source construct was "struct"
> (public by default) or "class", though.  But it sounds like we can't
> remove the public child now anyway.
>

Re: Language of registers

[Vladimir Prus]

On Monday 27 November 2006 17:03, Daniel Jacobowitz wrote:

> 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.

Documented or not, it seems Eclipse will break if we take it away. When 
opening a structure, code in 

    org.eclipse.cdt.debug.mi.core.cdi.model.Variable.getChildren 

assumes that is you have real (non-fake) structure, then all children of it 
are fake. It means that if you have 

	struct S { int i; };
        S s;

and create varobj V for 's' and 'i' becomes the immediate child of V, then
Eclipse will think V.i is fake child. Amoung other thing it will think that 
expression corresponding to 'V.i' is 's' -- not 's.i'. 

I don't know what to do about it. The right way is to 
implement -var-info-path-expression and get all frontends to update, and then 
remove 'public' for structures that have only public fields.

- Volodya