From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id CC9843858D32 for ; Mon, 29 May 2023 15:54:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CC9843858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.170] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (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 467491E0D6; Mon, 29 May 2023 11:54:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1685375658; bh=xPk5bnLPBAxnuwzdGocGTn6q/TmR29skstwq849i5m0=; h=Date:Subject:To:References:From:In-Reply-To:From; b=bttzuNFHQaivnffpx8ST0ETZwsWYZq/lRDP6iXH50EYsRn6h1QSfZj0iuufwfw38t EYm6ohaeSBXp3RSRGmJjDYc0wf2YoKSaKsekMbaH6kLx3G19+HU1InlcGaEchcqP7h 9cPRyxZ5tTTs8xAomHRwWG8r2M7Ba1PJbbb2PYss= Message-ID: <3f4fa15a-29f0-f1bb-f824-fbe9d344c397@simark.ca> Date: Mon, 29 May 2023 11:54:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.1 Subject: Re: [PATCH v2 8/9] Implement gdb.execute_mi To: Tom Tromey , gdb-patches@sourceware.org References: <20230404-dap-loaded-sources-v2-0-93f229095e03@adacore.com> <20230404-dap-loaded-sources-v2-8-93f229095e03@adacore.com> Content-Language: fr From: Simon Marchi In-Reply-To: <20230404-dap-loaded-sources-v2-8-93f229095e03@adacore.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 5/18/23 16:18, Tom Tromey via Gdb-patches wrote: > This adds a new Python function, gdb.execute_mi, that can be used to > invoke an MI command but get the output as a Python object, rather > than a string. This is done by implementing a new ui_out subclass > that builds a Python object. Hi Tom, My patch here: https://inbox.sourceware.org/gdb-patches/48eb5ee9-53e1-f1df-b424-d08342c7e857@simark.ca/T/#m94825956483bc1d340da33ad4712752d3326fecf conflicts with this patch, so I am taking a closer look at gdb.execute_mi. I think some things are missing from the gdb.execute_mi implementation, one way to expose some are to try: (gdb) python gdb.execute_mi('-gdb-exit') First, I think that the new mi_execute_command function should install the mi interpreter as the current interpreter (or the command interpreter, I don't really understand the distinction) such as code down mi_execute_command gets the mi_interp object when calling current_interpreter. There are not a lot of commands getting the current interpreter, but -gdb-exit is one of them. I tried fixing this quickly, but it's not just a oneliner. We need to ens The other places that get the current interpreter are mostly in the observers that output notifications. So that got me wondering, what should we do with any MI notification happening during the execution of the MI command? MI notifications are often suppressed during the execution of MI commands, but I suspect that there might some legitimate cases where notifications would go through. I was wondering what to do about them. They are written directly to mi->raw_stdout, so they would likely just appear on the terminal. Should we just make them go to /dev/null? Should we accumulate them and return a list of notifications as part of gdb.execute_mi's return value? Should the caller of gdb.execute_mi be able to provide a callback that gets called whenever there is a notification? The latter has the advantage that the Python code get notified immediately when the notification is sent, rather than receiving them all at once when the command's execution is complete. For something like -target-download, it might be interesting. It also has the advantage that it can be implemented later without breaking gdb.execute_mi (just add an optional parameter). Whereas the solution of returning them as a list would require changing gdb.execute_mi now, to avoid doing a breaking change later. Simon