From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122053 invoked by alias); 5 Jun 2015 12:40:44 -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 122040 invoked by uid 89); 5 Jun 2015 12:40:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,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 12:40:42 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 24D32C1F00; Fri, 5 Jun 2015 12:40:41 +0000 (UTC) Received: from host1.jankratochvil.net (ovpn-116-44.ams2.redhat.com [10.36.116.44]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t55CeaFD015470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 5 Jun 2015 08:40:38 -0400 Date: Fri, 05 Jun 2015 12:40: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: <20150605124035.GA1995@host1.jankratochvil.net> References: <20150604193820.GA18453@host1.jankratochvil.net> <86d21ao5vw.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d21ao5vw.fsf@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00081.txt.bz2 On Fri, 05 Jun 2015 11:34:43 +0200, Yao Qi wrote: > Jan Kratochvil writes: > > Patch implementing '@' GDB array operator in GCC has been rejected: > > https://gcc.gnu.org/ml/gcc-patches/2015-06/msg00414.html > > and so there is now a GDB tracker to implement it just in GDB: > > https://sourceware.org/bugzilla/show_bug.cgi?id=18489 > > If '@' is rejected in GCC, why do we need to support it in "compile" > feature in GDB? The manual of command "compile print" says: > > Compile and execute expr with the compiler language found as the > current language in GDB > > '@' isn't a valid operator for C language, we should emit error here. '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. Whether the manual wording is right or not is up to Eli. > IMO, "compile" feature should *only* accept valid source code according > to the language spec and the compiler. GDB 'compile print' should ideally accept all the features of GDB 'print' command. There is an internal TODO list: ------------------------------------------------------------------------------ * Add some gdb extensions to the GCC C parser. * "@" could be handled by having it create a new array * Convenience variables could be handled with perhaps some difficulty * Hack the parser to recognize them and call into gdb * Use copy-in/copy-out semantics as we do for registers * Use the variable value's current type and recompile the expression when the type changes (even trickier than it seems because the variable can be reassigned from inside the code) * Convenience functions are much harder. Maybe they could be done by annotating them with type information and then arranging for call-backs to gdb. It's likely that this isn't worth the effort; perhaps better would be to expose interesting and relevant gdb state to the compiled expressions somehow * "::" could be handled by hacking the parser * gdb's extended "." could also probably be handled * Not sure if the two {...} extensions are doable or not -- would need research to see if they introduce ambiguous parses. These are: * you can use {...} to make an array: (gdb) print {1,2,3,4} (gdb) ptype {1,2,3,4} type = int [4] * the cast-like '{int} foo' ------------------------------------------------------------------------------ These GDB operators (currently only '@') probably should not be supported by 'compile code' / 'compile file'. > 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? > > - xfail "$test (gcc does not support '@')" > > + kfail compile/18489 "$test" > > I think xfail is correct as gcc doesn't support '@'. This does not match the original plan of the 'compile' project. Jan