Re: -var-info-path-expression

[Daniel Jacobowitz <drow at false dot org>]

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