From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6866 invoked by alias); 5 Jun 2015 16:13:22 -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 6847 invoked by uid 89); 5 Jun 2015 16:13:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f180.google.com Received: from mail-pd0-f180.google.com (HELO mail-pd0-f180.google.com) (209.85.192.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 05 Jun 2015 16:13:20 +0000 Received: by pdbki1 with SMTP id ki1so56278881pdb.1 for ; Fri, 05 Jun 2015 09:13:18 -0700 (PDT) X-Received: by 10.70.61.68 with SMTP id n4mr7304651pdr.78.1433520798682; Fri, 05 Jun 2015 09:13:18 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id le17sm7324962pab.2.2015.06.05.09.13.15 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 05 Jun 2015 09:13:17 -0700 (PDT) From: Yao Qi To: Jan Kratochvil Cc: Yao Qi , gdb-patches@sourceware.org, Phil Muldoon Subject: Re: [obv] compile-print.exp: xfail->kfail for '@' GDB array operator References: <20150604193820.GA18453@host1.jankratochvil.net> <86d21ao5vw.fsf@gmail.com> <20150605124035.GA1995@host1.jankratochvil.net> Date: Fri, 05 Jun 2015 16:13:00 -0000 In-Reply-To: <20150605124035.GA1995@host1.jankratochvil.net> (Jan Kratochvil's message of "Fri, 5 Jun 2015 14:40:35 +0200") Message-ID: <868ubynnfw.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00087.txt.bz2 Jan Kratochvil writes: > 'compile print' should one day replace the standard 'print' command, like= in > LLDB. Otherwise 'compile print' makes no sense. > > Now we can argue whether the '@' GDB operator is useful or not but I think > majority of GDB users considers it as useful. '@' 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. Command 'print' can be built on top of the 'compile print' stuff, with extra functionality to transform '@' to a valid language form. Is it possible? 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. >> It will be really confusing if we add some other things (like '@' in this >> case) which is out of the scope of the language. > > So why were these operators added to the GDB expression evaluator in the = first > place? > 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. > >> > - xfail "$test (gcc does not support '@')" >> > + kfail compile/18489 "$test" >>=20 >> I think xfail is correct as gcc doesn't support '@'. > > This does not match the original plan of the 'compile' project. 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'. --=20 Yao (=E9=BD=90=E5=B0=A7)