From: Vladimir Prus <vladimir@codesourcery.com>
To: gdb-patches@sources.redhat.com
Subject: variable objects and registers
Date: Wed, 29 Nov 2006 17:21:00 -0000 [thread overview]
Message-ID: <200611292020.47109.vladimir@codesourcery.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]
I was working on implementing a new MI command that creates variable objects
for registers, and I have something working good enough to discuss. This
patch lacks docs, but I wanted to make sure the interface is fine with
everybody before documenting it.
There are already some commands related to registers, for
example, -data-list-register-names. But for registers that are not just
integers, one has to use variable objects to property display them. As
result, output of -data-list-register-names goes directly to a number
of -var-create. It is more reasonable to have a command that immediately
produces variable objects.
Further, when memory-mapped registers are involved, gdb might want to group
them in some hierarchy. Using variable objects is a reasonable way to achieve
that.
This patch adds new command -var-registers that creates and returns a list of
variable objects for all registers gdb knows. The command takes one option --
the frame, which is specified just like for -var-create. While not all
registers are saved, and so gdb might not know values of some registers in
parent frames, for some registers it's possible, and frontends might want to
access those values.
Since the command creates several variable objects, it does not accepts a name
of varobj. Instead, it automatically generated names much like "var-create -"
does.
Here's example output:
-var-registers *
^done,registers={
{name="var1",exp="$eax",numchild="0",value="16",type="int"},
............
{name="var10",exp="$eflags",numchild="0",value="[ SF IF ID ]",
As soon as we add the code to display memory-mapped registers, there will be a
problem that existing frontends might wish to show the memory-mapped
registers, but not wish (at the moment) to modify the code for displaying
regular registers. I plan to address this by either adding new
attribute "register-kind" to the output, that can be either "core"
or "memory-mapped", or by adding an option to -var-registers that says what
registers to show. But that's for future.
Comments?
- Volodya
* mi/mi-cmds.h (mi_cmd_var_registers): New.
* mi/mi-cmds.c: Register "var-registers".
* mi/mi-cmd-var.c (create_varobj_in_frame): New function.
(mi_cmd_var_create): Use the above.
(mi_cmd_var_registers): New.
[-- Attachment #2: varobj_for_registers__gdb_mainline.diff --]
[-- Type: text/x-diff, Size: 5091 bytes --]
=== gdb/mi/mi-cmds.h
==================================================================
--- gdb/mi/mi-cmds.h (/patches/gdb/varobj_printing/gdb_mainline) (revision 2338)
+++ gdb/mi/mi-cmds.h (/patches/gdb/varobj_for_registers/gdb_mainline) (revision 2338)
@@ -105,6 +105,7 @@
extern mi_cmd_argv_ftype mi_cmd_thread_select;
extern mi_cmd_argv_ftype mi_cmd_var_assign;
extern mi_cmd_argv_ftype mi_cmd_var_create;
+extern mi_cmd_argv_ftype mi_cmd_var_registers;
extern mi_cmd_argv_ftype mi_cmd_var_delete;
extern mi_cmd_argv_ftype mi_cmd_var_evaluate_expression;
extern mi_cmd_argv_ftype mi_cmd_var_info_expression;
=== gdb/mi/mi-cmds.c
==================================================================
--- gdb/mi/mi-cmds.c (/patches/gdb/varobj_printing/gdb_mainline) (revision 2338)
+++ gdb/mi/mi-cmds.c (/patches/gdb/varobj_for_registers/gdb_mainline) (revision 2338)
@@ -153,6 +153,7 @@
{ "trace-stop", { NULL, 0 }, NULL, NULL },
{ "var-assign", { NULL, 0 }, 0, mi_cmd_var_assign},
{ "var-create", { NULL, 0 }, 0, mi_cmd_var_create},
+ { "var-registers", { NULL, 0 }, 0, mi_cmd_var_registers},
{ "var-delete", { NULL, 0 }, 0, mi_cmd_var_delete},
{ "var-evaluate-expression", { NULL, 0 }, 0, mi_cmd_var_evaluate_expression},
{ "var-info-expression", { NULL, 0 }, 0, mi_cmd_var_info_expression},
=== gdb/mi/mi-cmd-var.c
==================================================================
--- gdb/mi/mi-cmd-var.c (/patches/gdb/varobj_printing/gdb_mainline) (revision 2338)
+++ gdb/mi/mi-cmd-var.c (/patches/gdb/varobj_for_registers/gdb_mainline) (revision 2338)
@@ -68,16 +68,39 @@
/* VAROBJ operations */
+static struct varobj *
+create_varobj_in_frame (char *name, char *expression, char *frame)
+{
+ CORE_ADDR frameaddr = 0;
+ struct cleanup *cleanup;
+ enum varobj_type var_type;
+
+ if (strcmp (frame, "*") == 0)
+ var_type = USE_CURRENT_FRAME;
+ else if (strcmp (frame, "@") == 0)
+ var_type = USE_SELECTED_FRAME;
+ else
+ {
+ var_type = USE_SPECIFIED_FRAME;
+ frameaddr = string_to_core_addr (frame);
+ }
+
+ if (varobjdebug)
+ fprintf_unfiltered (gdb_stdlog,
+ "Name=\"%s\", Frame=\"%s\" (0x%s), Expression=\"%s\"\n",
+ name, frame, paddr (frameaddr), expression);
+
+ return varobj_create (name, expression, frameaddr, var_type);
+}
+
enum mi_cmd_result
mi_cmd_var_create (char *command, char **argv, int argc)
{
- CORE_ADDR frameaddr = 0;
struct varobj *var;
char *name;
char *frame;
char *expr;
struct cleanup *old_cleanups;
- enum varobj_type var_type;
if (argc != 3)
{
@@ -104,23 +127,8 @@
else if (!isalpha (*name))
error (_("mi_cmd_var_create: name of object must begin with a letter"));
- if (strcmp (frame, "*") == 0)
- var_type = USE_CURRENT_FRAME;
- else if (strcmp (frame, "@") == 0)
- var_type = USE_SELECTED_FRAME;
- else
- {
- var_type = USE_SPECIFIED_FRAME;
- frameaddr = string_to_core_addr (frame);
- }
+ var = create_varobj_in_frame (name, expr, frame);
- if (varobjdebug)
- fprintf_unfiltered (gdb_stdlog,
- "Name=\"%s\", Frame=\"%s\" (0x%s), Expression=\"%s\"\n",
- name, frame, paddr (frameaddr), expr);
-
- var = varobj_create (name, expr, frameaddr, var_type);
-
if (var == NULL)
error (_("mi_cmd_var_create: unable to create variable object"));
@@ -131,6 +139,58 @@
}
enum mi_cmd_result
+mi_cmd_var_registers (char *command, char **argv, int argc)
+{
+ int regnum, numregs;
+ struct cleanup *cleanup;
+ char *frame;
+
+ if (argc != 1)
+ error (_("mi_cmd_var_registers: Usage: FRAME."));
+
+ frame = xstrdup (argv[0]);
+ cleanup = make_cleanup (xfree, frame);
+
+ /* Note that the test for a valid register must include checking the
+ REGISTER_NAME because NUM_REGS may be allocated for the union of
+ the register sets within a family of related processors. In this
+ case, some entries of REGISTER_NAME will change depending upon
+ the particular processor being debugged. */
+
+ numregs = NUM_REGS + NUM_PSEUDO_REGS;
+
+ make_cleanup_ui_out_tuple_begin_end (uiout, "registers");
+
+ for (regnum = 0; regnum < numregs; regnum++)
+ {
+ if (REGISTER_NAME (regnum) != NULL
+ && *(REGISTER_NAME (regnum)) != '\0')
+ {
+ char *name;
+ char *expression;
+ struct varobj *var;
+ struct cleanup *cleanup_child;
+
+ name = varobj_gen_name ();
+ make_cleanup (free_current_contents, &name);
+
+ expression = xstrprintf ("$%s", REGISTER_NAME (regnum));
+ make_cleanup (xfree, expression);
+
+ var = create_varobj_in_frame (name, expression, frame);
+
+ cleanup_child = make_cleanup_ui_out_tuple_begin_end (uiout, NULL);
+ print_varobj (var, PRINT_ALL_VALUES, 1 /* print expression */);
+ do_cleanups (cleanup_child);
+ }
+ }
+
+ do_cleanups (cleanup);
+ return MI_CMD_DONE;
+}
+
+
+enum mi_cmd_result
mi_cmd_var_delete (char *command, char **argv, int argc)
{
char *name;
Property changes on:
___________________________________________________________________
Name: csl:base
+/all/patches/gdb/varobj_printing/gdb_mainline
next reply other threads:[~2006-11-29 17:21 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-29 17:21 Vladimir Prus [this message]
2006-12-05 21:16 ` Daniel Jacobowitz
2006-12-06 9:25 ` Vladimir Prus
2006-12-19 22:02 ` Daniel Jacobowitz
2006-12-06 10:57 Nick Roberts
2006-12-19 17:59 ` Vladimir Prus
2006-12-19 21:58 ` Nick Roberts
2006-12-20 18:39 ` Vladimir Prus
2006-12-20 20:34 ` Nick Roberts
2006-12-21 1:34 ` Nick Roberts
2006-12-21 6:34 ` Vladimir Prus
2006-12-21 7:57 ` Nick Roberts
2006-12-21 8:34 ` Vladimir Prus
2006-12-30 20:26 ` Daniel Jacobowitz
2006-12-30 20:41 ` Vladimir Prus
2006-12-30 20:50 ` Daniel Jacobowitz
2006-12-30 23:05 ` Nick Roberts
2006-12-21 6:43 ` Vladimir Prus
2006-12-21 8:34 ` Nick Roberts
[not found] ` <0E190425-7C4F-4C6E-B8B3-9A3FA79F6FE3@apple.com>
2006-12-21 23:30 ` Nick Roberts
[not found] ` <1B6B17FA-65DE-4CE2-9BE0-20DA74780EEA@apple.com>
2006-12-22 4:47 ` Nick Roberts
2006-12-22 6:23 ` Vladimir Prus
2006-12-22 6:51 ` Nick Roberts
2006-12-22 7:30 ` Vladimir Prus
2007-01-05 9:04 ` Vladimir Prus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200611292020.47109.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox