This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: -var-info-path-expression
> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 31 Aug 2007 13:57:04 +0400
> Cc: gdb-patches@sources.redhat.com
>
> > How about if you write a real-life example of the output generated by
> > both commands (i.e. with real expressions, not @var{something}), and
> > place both of the examples in each section to show how the two
> > commands differ? Alternatively, have only one example in each
> > section, and point to the other, as in "Contrast this with the output
> > generated by -var-info-path-expression below."
>
> How about this patch? If has real examples, and tries to stress the
> fact that -var-info-expression is only for UI presentation, while
> -var-info-path-expression is for getting an expression you can actually
> evaluate.
Thanks, this needs only a few minot fixes:
> +For example, if @var{a} is an array, and variable object
> +@var{A} was created for @var{a}, then we'll get this output:
It's wrong to use @var in this context: here, `a' and `A' are literal
symbols, they do not stand for something else. So you should use
@code, not @var.
> +Here, the values of @var{lang} can be @code{@{"C" | "C++" | "Java"@}}.
Again, "lang" is a literal string, so use @code.
> +For example, suppose @var{C} is a C++ class, derived from class
^^^
Please use "C@t{++}", it looks better in print.
> +@var{Base}, and that the @var{Base} class has a member called
> +@var{m_size}. Assume a variable @var{c} is has the type of
> +@var{C} and a variable object @var{C} was created for variable
> +@var{c}. Then, we'll get this output:
> +@smallexample
> +(gdb) -var-info-path-expression C.Base.public.m_size
> +^done,path_expr=((Base)c).m_size)
> +@end smallexample
Here, too, all the symbols should have the @code markup.
Thanks again for working on this.