Re: Language of registers

[Jim Ingham <jingham@apple.com>]

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