From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81532 invoked by alias); 31 Aug 2018 20:59:18 -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 81519 invoked by uid 89); 31 Aug 2018 20:59:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=dramatic, conclusion, arising, parsers X-HELO: gateway33.websitewelcome.com Received: from gateway33.websitewelcome.com (HELO gateway33.websitewelcome.com) (192.185.145.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Aug 2018 20:59:16 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway33.websitewelcome.com (Postfix) with ESMTP id 0CE0D61CA7 for ; Fri, 31 Aug 2018 15:59:14 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id vqVdfUFEd79N3vqVdfiCEL; Fri, 31 Aug 2018 15:59:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YLv8TAuTKJjIcwot53BlknTH+RiB4eP9MoDSqDeHDVc=; b=ww5nEz950YWULUWSB31di9nfcf rTjKaJc+YvANM+LTzaY9W201RfAlvVPnQ2wnX0VP1PFZRkKapcA5SHJfMta8bwrCCh4mbzZiBPyop dWG83FTygjFxrt08V05I/fNI1; Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:60398 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fvqVd-001VXV-Nh; Fri, 31 Aug 2018 15:59:13 -0500 From: Tom Tromey To: Philippe Waroquiers Cc: Andrew Burgess , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 2/2] gdb: Allow parenthesis to group arguments to user-defined commands References: <1535225533.1438.5.camel@skynet.be> <1535230403.1438.10.camel@skynet.be> <20180825224310.GA32506@embecosm.com> <87lg8q7ai7.fsf@tromey.com> <20180828184331.GJ32506@embecosm.com> <1535488137.7778.4.camel@skynet.be> <20180828232948.GK32506@embecosm.com> <1535663976.7778.12.camel@skynet.be> Date: Fri, 31 Aug 2018 20:59:00 -0000 In-Reply-To: <1535663976.7778.12.camel@skynet.be> (Philippe Waroquiers's message of "Thu, 30 Aug 2018 23:19:36 +0200") Message-ID: <87h8jaz1zz.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-08/txt/msg00882.txt.bz2 >>>>> "Philippe" == Philippe Waroquiers writes: Philippe> For what concerns the parenthesis based solution, it looks to not work Philippe> for some cases. Philippe> E.g. if I want to pass one argument (I am using single quotes to show the args Philippe> I want in the below examples): Philippe> 'a b) (c d' Philippe> then I need to use: Philippe> some_user_defined (a b) (c d) Philippe> but that is the same notation as if I want to pass 2 arguments Philippe> 'a b' and 'c d' Can you think of an actual example where this would be useful? My feeling is that there isn't one, though I'd be interested in tricky-but-plausible counter-examples. This feeling is why I'm generally ok with Andrew's idea. Philippe> And it would be nice if the mechanism used to quote args would Philippe> be compatible between user defined commands and native gdb commands. There is no universal quoting in gdb. Instead there are 3 common cases, plus the extras (neglecting MI, which is totally different and not relevant here): 1. Commands that take an expression. These are things like "print". Expressions are passed to the language parser, but language parsers have to follow some gdb rules: optionally terminate parsing at a top-level (unparenthesized) comma, and also terminate parsing at "if" or some other things (there is a mildly odd case for Ada tasks). 2. Commands that take a linespec. These can also take an expression via the "*" linespec, so linespecs end up following some expression rules. Often there are expressions after the linespec too, like break LINESPEC if EXPR or dprintf LINESPEC, "string", EXPR, EXPR... 3. Commands that use gdb_argv (or libiberty's buildargv, which is the same thing). These respect some simple quoting. However, the quoting is very simple, not like what you might expect from the shell, for example I don't think you can quote an embedded quotation mark of the same kind (that is, no "this has \"quotes\""). 4. Everything else. gdb commands are just given a string and some do whatever the author liked. Philippe> I have not understood the reference given by Tom that expressions Philippe> are terminated with , and that parenthesis stops this termination. Philippe> Is that described somewhere in the doc ? Philippe> The doc (or an example if this is not documented) will help Philippe> me to understand. I think it's largely undocumented, since some of these quirks are just constraints arising from gdb's implementation choices. Not having any rhyme or reason to command argument parsing has good and bad facets. The good is that the generally DWIM nature of commands means that usually you don't have to contort yourself to satisfy some parser. Like, you can "break foo.c:93" or "break function" rather than something like the old dbx "stop in" / "stop at" split. The bad of course is that you may sometimes want to quote something and not have any idea of how to do it: because there's no consistency; because the gdb_argv idea was not really thought through (that's my conclusion, I don't know the actual story); or perhaps because you've just tripped across some command that was implemented in a particularly bad way. Now, it would be great to fix this, at least for some subset of things. I find it hard to see a way forward, though. Breaking compatibility (see my post upthread) is unpleasant, unless maybe it is done in a very dramatic way, coupled with a major version bump and some kind of huge warning for users -- but that's also very hard to implement and release. One idea is to add a new standard way to parse arguments, for new commands. But of course then gdb just has 5 ways to do it ... :( Tom