From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 103136 invoked by alias); 6 May 2015 10:22:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 103119 invoked by uid 89); 6 May 2015 10:22:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 06 May 2015 10:22:47 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t46AMkjj012605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 6 May 2015 06:22:46 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t46AMfM5013540; Wed, 6 May 2015 06:22:44 -0400 Message-ID: <5549EB71.1070101@redhat.com> Date: Wed, 06 May 2015 10:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org, Phil Muldoon Subject: Re: [PATCH v3 8/9] compile: New compile printf References: <20150411194322.29128.52477.stgit@host1.jankratochvil.net> <20150411194429.29128.61494.stgit@host1.jankratochvil.net> <5540FE29.5050004@redhat.com> <20150503140605.GC18394@host1.jankratochvil.net> In-Reply-To: <20150503140605.GC18394@host1.jankratochvil.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-05/txt/msg00089.txt.bz2 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