Re: [PATCH v3 8/9] compile: New compile printf

[Pedro Alves <palves@redhat.com>]

On 05/03/2015 03:06 PM, Jan Kratochvil wrote:
> On Wed, 29 Apr 2015 17:52:09 +0200, Pedro Alves wrote:
>> The usefulness of "compile printf"
>> specifically isn't as immediately clear though.  I think the manual
>> should say something about why you want to use "compile printf" over
>> the alternatives.  (Edit: Ah, I see that's in the next patch.)
> 
> I do not know, I have never used the existing GDB printf command myself.
> GDB Manual could describe what the existing GDB printf command is good for.

It's useful for formatted output in user-defined commands, without
using extension languages.  But indeed it's not clear what
"compile printf" in its current form is really useful for.

> IMO in the cases where one needs the printf command one already has to use
> some extension language (such as Python) which can do that on its own.

(The printf command predates extensions languages.)

> This patch was created upon request by Phil.

I'm wondering / trying to understand why we're making
"compile printf" do the printf-ing in the inferior.  It seems we may
be making our lives harder for possibly no good reason.

Consider where we'll ideally be in the future:

 #0 - by default, the compiler outputs intermediate IR which is
      interpreted by gdb, instead of injecting and calling code
      in the inferior.

 #1 - all expression evaluation goes through the compiler.

 #2 - the user no longer needs to know to use "compile "
      prefixed commands.  Instead, "print" etc. just use the compiler
      when possible, or when the user asks for it with some option.

With these in mind, maybe a better direction is to make

  (gdb) compile printf "%s, %d", expr1, expr2

instead evaluate expr1 and expr2 using the "compile print"
mechanism to get the values of expr1 and expr2, and
then do the printf formatting all on the gdb side, just
like "(gdb) printf".  Basically, in the current
sequence for "printf":

  printf_command -> ui_printf -> parse_to_comma_and_eval

Make parse_to_comma_and_eval eval using the compiler.

This avoids all the complication related to calling printf
in the inferior, which would necessarily behave differently
with #0 above (gdb's printf vs inferior's printf).

> 
>> The main advantage is that after the next patch, the output always
>> appears in gdb's console, while "compile code printf" works just like
>>   (gdb) print printf (...)
>> meaning, in the "compile the output should go to the inferior's stdout.
>>
>> Or is there another advantage I missed, perhaps?
> 
> This patch is just to split it to two mails for review. 

I understand that.  But what I was asking is (after the series is wholly
pushed), what is the advantage of "(gdb) compile printf"
over "(gdb) compile print printf (...)" and "(gdb) call printf (...)".

> I do not think it
> makes sense on its own, it messes up debugging output with inferior output.
> 
> 
>> But can give an example of why you'd want to set "set compile-printf-args"
>> differently to "set compile-args" ?
> 
> I do not know exactly myself but currently there is already:
> 	+  compile_printf_args = xstrdup ("-Werror=format");
> 
> so one may need to modify that for whatever reason.  I do not think there
> should be non-overridable GCC options.

Agreed on the latter, but the question really is: why do we need
"set compile-printf-args" instead of using "set compile-args" for
all expression evaluation through the compiler?
Shouldn't "-Werror=format" be in "set compile-args" too?
The fewer knobs the user must learn the better, and I'd like to
avoid ending up with a bunch of "set compile-foo-args" knobs
if possible.

Thanks,
Pedro Alves