From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75344 invoked by alias); 5 Jun 2015 21:23:24 -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 75320 invoked by uid 89); 5 Jun 2015 21:23:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no 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; Fri, 05 Jun 2015 21:23:22 +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 (Postfix) with ESMTPS id 2DB112DC43A; Fri, 5 Jun 2015 21:23:21 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55LNHlQ000433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Jun 2015 17:23:19 -0400 Date: Fri, 05 Jun 2015 21:23:00 -0000 From: Jan Kratochvil To: Yao Qi Cc: gdb-patches@sourceware.org, Phil Muldoon Subject: Re: [obv] compile-print.exp: xfail->kfail for '@' GDB array operator Message-ID: <20150605212316.GA12230@host1.jankratochvil.net> References: <20150604193820.GA18453@host1.jankratochvil.net> <86d21ao5vw.fsf@gmail.com> <20150605124035.GA1995@host1.jankratochvil.net> <868ubynnfw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <868ubynnfw.fsf@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00088.txt.bz2 Hi Yao, I have replied to all your arguments but I think it is just enough to say: 'compile print' is a work in progress to become future 'print'. On Fri, 05 Jun 2015 18:13:07 +0200, Yao Qi wrote: > '@' is useful in command print, and it is reasonable for me to replace > command print with 'compile print' one day, I agree on them. If gcc > doesn't accept '@', 'compile print' shouldn't as well, but 'print' can. That depends what 'compile print' should do. IMO it is "future 'print'". So I do not understand why you say: 'compile print' shouldn't [...], but 'print' can. > Command 'print' can be built on top of the 'compile print' stuff, 'print' should be replaced by 'compile print'. 'compile print' is a work in progress towards that goal. If you want we can create 'compile print2' which will be "future 'print'" while 'compile print' can remain ISO C (or whatever language GCC is configure to accept) clean. But then I do not see what 'compile print' would be good for, 'compile print2' would supersede it in all aspects. Besides that there is currently no kind of 'print' command unsupporting GDB extensions so I do not understand why you want 'compile print' to have one. > with extra functionality to transform '@' to a valid language form. Is it > possible? Everything is possible but I do not see usefulness of multiple commands where one is a subset of functionality of other. The general goal should be reducing the number of commands/options of GDB, not the opposite. > Anyway, I suggest we consider support '@' when we really start > considering replace 'print' command with 'compile print' command. Once > we support '@' in 'compile print', we can't remove it. I am inclined to > postpone the decision to some time we really need it. 'compile print' should be already useful in some cases (such as evaluating macros containing statement expressions) although I admit I haven't yet had an opportunity to utilize it (primarily because there is no inferior C++ 'compile' support yet). I was proposing to implement the discussed command set compile print {never|always|preferred|deferred} as it makes sense already; but I was assigned to other priorities so far. > I don't know, but GDB expression (which supports '@') is not a language, > so it is flexible to add and remove operators. Commands 'compile XXX' > are different, because their input is source language, and IMO we > shouldn't add any extensions to the source language. I do not understand why you find the goals of 'compile print' and 'print' to be different. > Where is the original plan? > https://sourceware.org/gdb/wiki/GCCCompileAndExecute is the only thing I > can find, but I don't see the anything about replacing command 'print' with > 'compile print'. The plan is to support all the features of LLDB which uses clang/llvm for its 'print' command. Although it may not be a great argument as LLDB does not support the '@' operator at all. Jan