From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93771 invoked by alias); 29 Apr 2015 15:52:14 -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 93161 invoked by uid 89); 29 Apr 2015 15:52:14 -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, 29 Apr 2015 15:52:13 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 3247A5D for ; Wed, 29 Apr 2015 15:52:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3TFq91G031417; Wed, 29 Apr 2015 11:52:10 -0400 Message-ID: <5540FE29.5050004@redhat.com> Date: Wed, 29 Apr 2015 15:54: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 , gdb-patches@sourceware.org CC: 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> In-Reply-To: <20150411194429.29128.61494.stgit@host1.jankratochvil.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg01078.txt.bz2 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