This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: -var-info-path-expression
On Sun, Jan 28, 2007 at 12:48:36AM +0300, Vladimir Prus wrote:
> I guess I do know -- I don't care about minor interface details. It's more
> important to have this implemented than solving "attribute vs. command"
> question the right way, and therefore, using a separate command is fine.
>
> Do you want me to add docs/tests or you can review the current
> version of the patch, reposted here fore convenience?
I'll just review this copy. I think having it pop out of
-var-list-children automatically would be useful, but the testsuite
updates would be a pain - maybe we should keep that in mind when
we add tests for new MI commands and try to use more functions.
> + if (argc != 1)
> + error ("mi_cmd_var_info_path_expression: Usage: NAME.");
> +
> + /* Get varobj handle, if a valid var obj name was specified */
> + var = varobj_get_handle (argv[0]);
> + if (var == NULL)
> + error ("mi_cmd_var_info_path_expression: Variable object not found");
Missing _(). Also, we didn't update existing commands, but I think we
decided the "function:" prefixes weren't helpful.
> @@ -757,6 +779,21 @@ varobj_get_gdb_type (struct varobj *var)
> return var->type;
> }
>
> +/* Return a pointer to the full rooted expression of varobj VAR.
> + If it has not been computed yet, compute it */
> +char *
> +varobj_get_path_expr (struct varobj *var)
> +{
> + if (var->path_expr != NULL)
> + return var->path_expr;
> + else if (is_root_p (var))
> + return var->name;
> + else
> + {
> + return (*var->root->lang->path_expr_of_child) (var);
> + }
> +}
Since you initialize path_expr at the same time as name, will is_root_p
ever trigger here?
> @@ -1826,10 +1875,13 @@ value_struct_element_index (struct value
> to NULL. */
> static void
> c_describe_child (struct varobj *parent, int index,
> - char **cname, struct value **cvalue, struct type **ctype)
> + char **cname, struct value **cvalue, struct type **ctype,
> + char **cfull_expression)
Nick's got a point about the growing number of arguments. Would
converting them to a struct simplify it?
struct varobj_child_desc
{
char *name;
struct value *value;
struct type *type;
char *full_expression;
};
Hey... those fields all live in struct varobj... I wonder if this code
ought to be rearranged so that this initializes the child's struct
varobj. But anyway let's not do that right now. The new argument is
fine, I was just thinking out loud.
--
Daniel Jacobowitz
CodeSourcery