From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yPPiDfdVlWBRRQAAWB0awg (envelope-from ) for ; Fri, 07 May 2021 11:00:07 -0400 Received: by simark.ca (Postfix, from userid 112) id 30EB61F11C; Fri, 7 May 2021 11:00:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 8F16E1E01F for ; Fri, 7 May 2021 11:00:04 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 295DC3853830; Fri, 7 May 2021 15:00:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 295DC3853830 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1620399604; bh=1W486qsRLFgaWMCEkwAf+RuQxpnzlE9pxNeLFCNaZhQ=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=X9053/sJ1yhcXxC1TC8NjPQAub0pRK9kOElg/GMfZX+kJttrvUYoywW/qDqfhLX2R sGIvPrV3Q9Sg6lV2QKrGBaDyhOXvAWyI3AL8q2Mbg1d53pU8e6ru+C7z0ebOKgZ5c3 nrMy3Q2Sia5Ti3N/GJnVq/CRDjK/go4RfUZlTpgo= Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id 2EB07385382D for ; Fri, 7 May 2021 15:00:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2EB07385382D Received: by mail-oi1-x236.google.com with SMTP id n184so8909883oia.12 for ; Fri, 07 May 2021 08:00:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1W486qsRLFgaWMCEkwAf+RuQxpnzlE9pxNeLFCNaZhQ=; b=VmdhAc9wt//itUO8808spW+WqzzfwZKRy6nqJIkbz2UYUlbV+9qKwTTMkJpPJMmU6z kdHMPbjt2KtYKXFmU+SsvCQzVwo6sQ1Gvpj113gbhg6/F9reEIzHUGt/eYbYxLF0OpBU opBPrCuf8zUBkPwxyt0KvmRDEy6VeIcJF2Re1c7LwJCIbBW8BJJpQOvtZLJHcJ6kJX8j HH5Ly/+8J4BvhVrGbfPZb7AFaUpQvwkahhy+pEWYLpxyvlhiQkgyoMcaJf3OCVzqcYvG C3ZPKNrFJ2HM6bgO1c91E/6vBKvlEP7RlT3QAbA/wEpFkYf7yO7ej8bNhxXr5igShHZ5 qpmg== X-Gm-Message-State: AOAM533RnihFG/n2i0ansPhQ4OcyB75NEgEqx40ox8FibBvwoUtYj+Wq gb0IvvQoKnJT+r2N+yxalgw34dKcONOO/P6ZzwBYRw== X-Google-Smtp-Source: ABdhPJw8zlxlu65lnzE3srwTA16AJYy6clkqCIuHhiPu6F4GJBlWt/AcGEEDY8PeNoRfIHz7KJXy+PiVB62I1wwdp94= X-Received: by 2002:a05:6808:609:: with SMTP id y9mr15385685oih.174.1620399600571; Fri, 07 May 2021 08:00:00 -0700 (PDT) MIME-Version: 1.0 References: <20210108100706.96190-1-mbarisione@undo.io> <20210125112649.56362-1-mbarisione@undo.io> <20210125112649.56362-3-mbarisione@undo.io> <1f3b725d-4b0a-d9ab-7553-24b52b3ff256@polymtl.ca> In-Reply-To: Date: Fri, 7 May 2021 15:59:24 +0100 Message-ID: Subject: Re: [PATCH v2 2/5] gdb: prevent prefix commands from being hooks To: Simon Marchi Content-Type: text/plain; charset="UTF-8" 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: Marco Barisione via Gdb-patches Reply-To: Marco Barisione Cc: GDB patches mailing list Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Tue, 16 Mar 2021 at 03:17, Simon Marchi wrote: > I mentioned in a previous review (somewhere in the default-args series, > I can't find it right now) that I was not too comfortable in having > features allowing modifying the behavior of builtin commands in > undocumented ways. You could say that hooks are a way to do that. But > at least, even if you define a hook-backtrace, the backtrace part still > works as usual, just that there are some things happening before. Maybe > I'm a bit too afraid that some script I'm using breaks some other script > I'm using because it decided to rename some core command... > > But I see why that would be useful (we use proc renaming in TCL for the > testsuite). It's a tradeoff, with powerful tools you can go great > things but are also more likely to shoot yourself in the foot. And I > guess we can't protect the users from themselves for everything, > otherwise our tool is useless. And since the concept was deemed ok by > other reviewers / maintainers previously, I won't object to it. You won't object to the concept, but how about this specific patch? :) Is there anything to change? If not, should it wait for the main command renaming one before going in? -- Marco Barisione