Re: pr 11067 patch

[Vladimir Prus <vladimir@codesourcery.com>]

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