This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Language of registers

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


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]