From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wDg2CAeYRmDDbwAAWB0awg (envelope-from ) for ; Mon, 08 Mar 2021 16:32:55 -0500 Received: by simark.ca (Postfix, from userid 112) id 13E7F1EF78; Mon, 8 Mar 2021 16:32:55 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 51FF81E789 for ; Mon, 8 Mar 2021 16:32:54 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 701443861971; Mon, 8 Mar 2021 21:32:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 701443861971 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1615239173; bh=g7di4hOuwvu98jxpGzf0W6/X/FORRMXtNmIV7Mj5Z7Y=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=dUifFWytpmnwL/IQb1VfzRGDiOI1oTaM1zTRrTM0gZGeicE55iKj6ddFfBqvKkUNC cRKldl+XzHoAurRPFt7Ydkcia3P6l9UHt2w+3AEB0SXPZ2mC9MPaoXvrK9atS0Vtls 1meSC+FekOUmIrHkAnbiG5tad9aKgExSM00KWtvQ= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id AB0B23861971 for ; Mon, 8 Mar 2021 21:32:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AB0B23861971 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 128LWjvV012484 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Mar 2021 16:32:49 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 128LWjvV012484 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 961261E789; Mon, 8 Mar 2021 16:32:44 -0500 (EST) Subject: Re: [PATCH v2 2/5] gdb: prevent prefix commands from being hooks To: Marco Barisione , gdb-patches@sourceware.org References: <20210108100706.96190-1-mbarisione@undo.io> <20210125112649.56362-1-mbarisione@undo.io> <20210125112649.56362-3-mbarisione@undo.io> Message-ID: <1f3b725d-4b0a-d9ab-7553-24b52b3ff256@polymtl.ca> Date: Mon, 8 Mar 2021 16:32:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210125112649.56362-3-mbarisione@undo.io> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 8 Mar 2021 21:32:45 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 2021-01-25 6:26 a.m., Marco Barisione via Gdb-patches wrote: > Currently it's possible for hooks to be prefix commands: > > define-prefix hook-run > > define hook-run > echo Will run!\n > end > > define hook-run subcommand > echo Subcommand\n > end > > Then: > > (gdb) run > Will run! > [...] > (gdb) hook-run subcommand > Subcommand > > This doesn't seem very useful or worse, it can be confusing. Moreover, > this creates some obscure corner cases in a later patch adding command > renaming. > > Because of this, this patch prevents hooks to become prefixes and > prefixes to become hooks. > > An alternative approach would have been to prevent prefixes starting > with "hook-" or "hookpost-". The end result would have been similar > but not identical as GDB allows commands starting with "hook-" or > "hookpost-" which are not hooks (for instance, "define > hook-this-doesnt-exist"). To be more consistent with this use case, > prefixes for commands which are named like hooks but are not hooks are > allowed. Ahhh, changes that touch command handling are always scary stuff, we need to be really careful not to break existing use cases or paint ourselves in corners for future use cases. Probably why nobody dares to review it. I'll give it a try, but know that it still scares me :). One question that pops up is, what if someone ever wants to make a hook for a prefixed command. For example, let's say I want to hook "info inferiors". I don't think that's possible today, but let's say we want to make it possible. How would that work? This doesn't work: (gdb) define hook-info inferiors Undefined command: "hook-info". Try "help". So... maybe defining "hook-info" as a prefix command would allow it? Not sure, I didn't really think this through, but I wonder if you thought about that case. Simon