From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130258 invoked by alias); 6 Nov 2019 08:42:32 -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 130243 invoked by uid 89); 6 Nov 2019 08:42:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=ont, up, love X-HELO: mail-wm1-f68.google.com Received: from mail-wm1-f68.google.com (HELO mail-wm1-f68.google.com) (209.85.128.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2019 08:42:30 +0000 Received: by mail-wm1-f68.google.com with SMTP id z26so2316238wmi.4 for ; Wed, 06 Nov 2019 00:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=undo-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+MGJpAQI/ABeXCInnpUpVkbPC/MzMRMTUCkfl9c4N3Y=; b=V/ulNFmszpl9uKqK38izjpAn9Hz9IbXEL3BFGHkbM5iLrS504zavNOvPAJIyoqG578 no5tW7lTuwWLGk+xdsPFK09RCu14VQP3qJ9Fc0Qkt885Ol0t++anXxqVpPcniz19RU6c hoTwf/FWCD6IyPWxBcICq6IHIhrHz9Exh6cc0Pv5wUxO5WafgzAlKfOeTjhgFBj+BwMV h2CwjOLKzS1xq2m5FYwl0LkvdU9Hyyjano5eXofJgyp9eyVW2SNz7KsQLGu8VJkTb9Zw 2crmhzsJdNXaB+tlYxFznPDdp4xnSUsXhb+DB+Nhdoofm8jr4WCRgg7wVnzNJQ0q2jln 0z8g== Return-Path: Received: from [192.168.0.108] (cpc91242-cmbg18-2-0-cust276.5-4.cable.virginm.net. [82.8.129.21]) by smtp.gmail.com with ESMTPSA id t24sm35437760wra.55.2019.11.06.00.42.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 00:42:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: [PATCH v2] Add a way to preserve overridden GDB commands for later invocation From: Marco Barisione In-Reply-To: <20191105101745.GC11037@embecosm.com> Date: Wed, 06 Nov 2019 08:42:00 -0000 Cc: Tom Tromey , gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <82352974-6E4A-4711-9911-172F04F2CE14@undo.io> References: <20191028133234.319-1-mbarisione@undo.io> <20191101085449.28493-1-mbarisione@undo.io> <87wocj1k3y.fsf@tromey.com> <2E9BBFD2-6643-4958-AF6B-FFC974FFF479@undo.io> <20191105101745.GC11037@embecosm.com> To: Andrew Burgess X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00145.txt.bz2 On 5 Nov 2019, at 10:17, Andrew Burgess wrote: > * Marco Barisione [2019-11-01 21:01:18 +0000]: >> Let's say you override delete. Let's call the first class overriding it >> DeleteCommand1 and the second DeleteCommand2. >>=20 >> If DeleteCommand1 didn't use preserve_when_overridden then >> DeleteCommand2.invoke_overridden will just call the original delete. >>=20 >> If DeleteCommand1 was preserved, then DeleteCommand2.invoke_overridden >> will call DeleteCommand1.invoke. At this point DeleteCommand1 may just = do >> whatever it needs on its own, or call its own invoke_overridden method >> which will call the original delete command. >> DeleteCommand2 has not way to invoke the original delete command directl= y. >> This is partly because I'm not sure how I would expose this in a nice wa= y, >> but mainly because I don't want commands to accidentally skip some >> previous implementation by accident. For instance, if we had an >> invoke_original method, then DeleteCommand2 could call that and skip >> DeleteCommand1. >=20 > I too have sometimes wondered about providing override type > behaviour. >=20 > I wonder, instead of having 'invoke_overridden' and/or > 'invoke_original', if we could/should look to TCL for inspiration, > specifically it's uplevel command[1]. Hm, I think this is potentially a very good idea. I=E2=80=99m slightly worried about people accidentally (or on purpose but w= ithout understanding the consequences) skipping a new command implementation, but it=E2=80=99s probably not a big deal. I would suggest the method to be uplevel_command(args, from_tty[, level]) so, if you don't specify the level, you just invoke the directly overridden command. > If we consider your 'delete' example, the builtin delete would be > considered to be at level 0, then we define DeleteCommand1, this would > be level 1, and then comes DeleteCommand2 which would be at level 2. >=20 > Inside DeleteCommand1 we can do: >=20 > DeleteCommand1.invoke_uplevel (-1, args) >=20 > this would invoke the command one level down the stack, so in this > case the builtin delete. In DeleteCommand2 we can do: I would say this is level 1, not level -1. This would match TCL, make more sense with the name (IMHO) of the method as it says "up=E2=80=9D, and = make the common case use positive numbers, not negative ones. Does it make sense to have a level of 0? Why not just calling the invoke method directly? How about negative numbers? Why would you need it? It seems it's risky as you could easily create cycles. It would also mean that an overridden command would need to know that it was overridden and that the overriding command if not going to blindly call back the overridden command. Because of this, I *think* it would make more sense (at least in the first version of this patch until we find a use case) to just have level > 0 (or >=3D 0). > Where I would find this idea really interesting is that we could > easily provide access to this functionality from the command line. > This might be useful in two ways I think, first, if a Python script > has overridden a command and a user wants to quickly bypass that for > some reason they can just do: >=20 > (gdb) uplevel 0 delete args=E2=80=A6 I love this! Why 0? Shouldn=E2=80=99t this be -1 following your example above? Like I said above I think this would be simpler if level were > 0 and optional: uplevel delete 42 Or: uplevel 1 delete 42 > in order to get the base version of the command. Second, with some > extra work we could make the existing hook mechanism redundant, and > possibly provide something more flexible (maybe?), consider: >=20 > define delete > echo Basically a pre-hook here\n > uplevel -1 delete $argv > echo Basically a post-hook here\n > end Being able to avoid hooks is one of the reasons for this patch. Currently, in my code, I have a lot of hooks which just call into Python but they are ugly (GDB Script code to just call into Python) and they cannot prevent the command from being executed without a Python stacktrace being printed (ont very nice for users). I'd be happy to provide uplevel as part of this patch. > Notice I just invented '$argv' on the fly there - this doesn't exist > currently, but I'm imagining that this would expand to all of the > arguments passed to the newly defined 'delete' command. >=20 > Anyway, I don't think all of the ideas mentioned above would need to > be implemented in one go, but I thought it might be worth mentioning > some of the thoughts I'd had in this area. I=E2=80=99d skip the $argv thing for this patch but I think it makes sense. How would the from_tty argument for C or Python command be defined? --=20 Marco Barisione