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: Mon, 27 Nov 2006 13:39:08 +1300
- Subject: Re: Language of registers
> 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