public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>, gdb-patches@sourceware.org
Cc: Phil Muldoon <pmuldoon@redhat.com>
Subject: Re: [PATCH v3 8/9] compile: New compile printf
Date: Wed, 29 Apr 2015 15:54:00 -0000	[thread overview]
Message-ID: <5540FE29.5050004@redhat.com> (raw)
In-Reply-To: <20150411194429.29128.61494.stgit@host1.jankratochvil.net>

On 04/11/2015 08:44 PM, Jan Kratochvil wrote:
> Hi,
> 
> command naming needs to follow what gets decided for 'compile print'.
> 
> This part sends the output to inferior stdout, only the next patch will
> redirect it to GDB (so that for example it works for remote gdbserver).
> 
> It cannot work for core files as one cannot execute inferior code there.
> There were some ideas such as compiling the entered sources into GCC
> intermediate form (GIMPLE?) and interpret it by GDB on top of the core file.

Yeah, though that's a general idea for "compile print" as well, not
just printf.  I'd love to see us get there, but these new commands
are useful on their own as interim steps too.  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.)

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?

> That would be much more complicated, this implementation is made according to
> Phil's specification.
> 
> Besides existing
> 	(gdb) set compile-args
> there will be now also:
> 	(gdb) set compile-printf-args
> Maybe it would be worth to start some set sub-category 'compile' such as:
> 	(gdb) set compile args
> 	(gdb) set compile printf-args

That'd be fine with me.

But can give an example of why you'd want to set "set compile-printf-args"
differently to "set compile-args" ?

> That would mean the whole process of deprecating 'set compile-args' etc.


> +  add_setshow_string_cmd ("compile-printf-args", class_support,
> +			  &compile_printf_args,
> +			  _("Set compile command GCC command-line arguments FIXME"),
> +			  _("Show compile command GCC command-line arguments FIXME"),

Some FIXMEs here.

Overall looks reasonable.

Thanks,
Pedro Alves

  reply	other threads:[~2015-04-29 15:52 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-11 19:43 [PATCH v3 0/9] compile: compile print&printf Jan Kratochvil
2015-04-11 19:43 ` [PATCH v3 3/9] Code cleanup: compile: Constify some parameters Jan Kratochvil
2015-04-29 15:47   ` Pedro Alves
2015-05-06 18:58     ` [commit] " Jan Kratochvil
2015-04-11 19:43 ` [PATCH v3 1/9] Code cleanup: Make parts of print_command_1 public Jan Kratochvil
2015-04-29 15:44   ` Pedro Alves
2015-04-30  0:24     ` Jan Kratochvil
2015-04-11 19:43 ` [PATCH v3 2/9] compile: Distribute scope, add scope_data Jan Kratochvil
2015-04-29 15:44   ` Pedro Alves
2015-04-11 19:44 ` [PATCH v3 7/9] compile: New 'compile print' Jan Kratochvil
2015-04-29 15:53   ` Pedro Alves
2015-05-03 14:06     ` Jan Kratochvil
2015-05-06 10:22       ` Pedro Alves
2015-05-06 12:23         ` Jan Kratochvil
2015-05-06 14:11           ` Pedro Alves
2015-05-06 19:18             ` Jan Kratochvil
2015-05-15 16:35               ` Pedro Alves
2015-04-11 19:44 ` [PATCH v3 6/9] Code cleanup: compile: func_addr -> func_sym Jan Kratochvil
2015-04-29 15:52   ` Pedro Alves
2015-04-11 19:44 ` [PATCH v3 4/9] compile: Support relocation to GNU-IFUNCs Jan Kratochvil
2015-04-29 15:48   ` Pedro Alves
2015-05-06 19:00     ` [commit] " Jan Kratochvil
2015-04-11 19:44 ` [PATCH v3 5/9] compile: Use -Wall, not -w Jan Kratochvil
2015-04-29 15:49   ` Pedro Alves
2015-05-03 14:05     ` Jan Kratochvil
2015-05-06 10:21       ` Pedro Alves
2015-04-11 19:44 ` [PATCH v3 8/9] compile: New compile printf Jan Kratochvil
2015-04-29 15:54   ` Pedro Alves [this message]
2015-05-03 14:06     ` Jan Kratochvil
2015-05-06 10:22       ` Pedro Alves
2015-05-06 11:30         ` Jan Kratochvil
2015-05-06 11:47           ` Pedro Alves
2015-04-11 19:44 ` [PATCH v3 9/9] compile: compile printf: gdbserver support Jan Kratochvil
2015-04-26  9:33   ` Jan Kratochvil
2015-04-29 18:19     ` Pedro Alves
2015-05-03 14:06       ` Jan Kratochvil
2015-05-06 10:22         ` Pedro Alves
2015-04-29 16:12   ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5540FE29.5050004@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@redhat.com \
    --cc=pmuldoon@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).