Re: [obv] compile-print.exp: xfail->kfail for '@' GDB array operator

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Fri, 05 Jun 2015 11:34:43 +0200, Yao Qi wrote:
> Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> > Patch implementing '@' GDB array operator in GCC has been rejected:
> > 	https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00414.html
> > and so there is now a GDB tracker to implement it just in GDB:
> > 	https://sourceware.org/bugzilla/show_bug.cgi?id=18489
> 
> If '@' is rejected in GCC, why do we need to support it in "compile"
> feature in GDB?  The manual of command "compile print" says:
> 
>   Compile and execute expr with the compiler language found as the
>   current language in GDB
> 
> '@' isn't a valid operator for C language, we should emit error here.

'compile print' should one day replace the standard 'print' command, like in
LLDB.  Otherwise 'compile print' makes no sense.

Now we can argue whether the '@' GDB operator is useful or not but I think
majority of GDB users considers it as useful.

Whether the manual wording is right or not is up to Eli.


> IMO, "compile" feature should *only* accept valid source code according
> to the language spec and the compiler.

GDB 'compile print' should ideally accept all the features of GDB 'print'
command.  There is an internal TODO list:
------------------------------------------------------------------------------
   * Add some gdb extensions to the GCC C parser.
     * "@" could be handled by having it create a new array
     * Convenience variables could be handled with perhaps some difficulty
       * Hack the parser to recognize them and call into gdb
       * Use copy-in/copy-out semantics as we do for registers
       * Use  the variable value's current type and recompile the expression when the  type changes (even trickier than it seems because the variable can be  reassigned from inside the code)
     * Convenience  functions are much harder.  Maybe they could be done by annotating them  with type information and then arranging for call-backs to gdb.  It's  likely that this isn't worth the effort; perhaps better would be to  expose interesting and relevant gdb state to the compiled expressions  somehow
     * "::" could be handled by hacking the parser
     * gdb's extended "." could also probably be handled
     * Not sure if the two {...} extensions are doable or not -- would need research to see if they introduce ambiguous parses.  These are:
       * you can use {...} to make an array:
                        (gdb) print {1,2,3,4}
                        (gdb) ptype {1,2,3,4}
                        type = int [4]
       * the cast-like '{int} foo'
------------------------------------------------------------------------------

These GDB operators (currently only '@') probably should not be supported by
'compile code' / 'compile file'.


> It will be really confusing if we add some other things (like '@' in this
> case) which is out of the scope of the language.

So why were these operators added to the GDB expression evaluator in the first
place?


> > -	xfail "$test (gcc does not support '@')"
> > +	kfail compile/18489 "$test"
> 
> I think xfail is correct as gcc doesn't support '@'.

This does not match the original plan of the 'compile' project.


Jan