This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Language of registers
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Vladimir Prus <vladimir at codesourcery dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 7 Dec 2006 10:49:57 +1300
- Subject: Re: Language of registers
> > 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