This is the mail archive of the gdb-patches@sourceware.org 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


> 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


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