Re: pr 11067 patch

Vladimir Prus
2010-02-22T09:22:55Z

On Friday 19 February 2010 23:11:05 Jan Kratochvil wrote:

> On Fri, 19 Feb 2010 20:51:36 +0100, Chris Moller wrote:
> > That limited the format change to unsummarised top-level "p <enum
> > thingy>" circumstances. If I make that test
> >
> > if (options->summary || recurse != 0 ||
> > ui_out_is_mi_like_p (interp_ui_out
> > (top_level_interpreter ())))
> >
> > i.e., checking if the print is to an MI whatever-it-is, the MI tests
> > that failed under the original patch (mi-var-display and
> > mi2-var-display) run okay as they originally were, which suggests to
> > me that MI will go on getting enums formatted the way it expects
> > them. Will that work?
>
> I would prefer the value_print_options way but rather:
>
>
> Vladimir, if CLI start print instead of
> (gdb) p enum_var
> $1 = enumerator2
> now:
> (gdb) p enum_var
> $1 = enumerator2 = (enum uenum) 2
>
> should MI also print this "pretty printed" enum syntax or should it stick with
> the original one? Therefore should be made this change?
>
> mi_gdb_test "-var-evaluate-expression anone" \
> - "\\^done,value=\"A\"" \
> + "\\^done,value=\"A = \\(enum <anonymous>\\)0\"" \
> "eval variable anone"

Hi Jan,

I am not 100% sure but I am concerned about the above output having 'enum uenum' --
which is essentially the type of the variable. And MI already reports type separately.
I recall I've made some changed before to specifically stop GDB from including the
type of variable inside value field when the type is function. So, I suggest that
this output is not included for MI. It might be OK to output a separate
field, e.g. "enum_integer_value" -- with the integer value as printed above -- but
I don't have a feeling if frontends really need that at this point.

Thanks,

--
Vladimir Prus
CodeSourcery
vladimir@codesourcery.com
(650) 331-3385 x722