From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsec111.isp.belgacom.be (mailsec111.isp.belgacom.be [195.238.20.107]) by sourceware.org (Postfix) with ESMTPS id 60FB03858D32 for ; Sat, 2 May 2020 23:01:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 60FB03858D32 IronPort-SDR: 1FNjzCMxRWLBk5m+d7xv4yNcHj+V4KO8ZsU76DFI5d7WhEMId527N12RCqlbVvfZJiCwA7iZeZ g19oFbSWRKlAqY7Sqx0AGI+CNu0STmVVxIwVKnqZvTiYCGG0DxXPHHOfzG6s44XhJLjl6om14S VbDq1J59rfZ8NOqtJvmS4szFWrn5QNFQRj5PMdJ/BJez7QWOrrEZSu92HBCFNvOW83KFBClX3n 1oet9catg0eIVn8wyZYatm2X2h+Twxmg298IFoqooFDb0l7621ZUJeYB2hmjYY9udgueivEN9Y n50= IronPort-PHdr: =?us-ascii?q?9a23=3ApgDagRSxzSOFVGi00N2C9Bpm9tpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa67ZBGPt8tkgFKBZ4jH8fUM07OQ7/m9HzNYqs/Y+Fk5M7V0Hy?= =?us-ascii?q?cfjssXmwFySOWkMmbcaMDQUiohAc5ZX0Vk9XzoeWJcGcL5ekGA6ibqtW1aFR?= =?us-ascii?q?rwLxd6KfroEYDOkcu3y/qy+5rOaAlUmTaxe7x/IAi2oAnLtMQanYRuJrssxh?= =?us-ascii?q?DUvnZGZuNayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG?= =?us-ascii?q?8p6sLlsxnDVhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XC?= =?us-ascii?q?mp4ql3RBP0jioMKiU0+3/LhMNukK1boQqhpx1hzI7SfIGVL+d1cqfEcd8HWW?= =?us-ascii?q?ZNQsNdWipcCY2+coQPFfIMM+VFoYf9uVUAoxmxBQewC+zhxTBGiWT73bE43u?= =?us-ascii?q?k7DQ3KwBYtEtAIvX/JrNv1LqASUeWtwafSzTXDbvdW2Tbl6IjQbB8qvPGDUq?= =?us-ascii?q?hqccrW0EkvCgLFgUuKqYz+IjiY0fwNs2ia7+pkVOKvk3YnpB9rrjmh3MgskI?= =?us-ascii?q?7JhpsIylDF6yp52p01KMajSE54Yd+kFoVftz2AO4RtXMwvWmdlszs1xbMao5?= =?us-ascii?q?C0ZjQKyIg5yB7FbfyKa5aE7gzgWeuNLjp0mG5pdbC/ihu97EWuyvHwW8a73l?= =?us-ascii?q?hKsydInN3Bu24D2RHN5MWKSfhw80mg1DuP2Q3e5eVJLEEymKHGKJAh2qY9mo?= =?us-ascii?q?QOvUnBBCP6hUv7ga6Mekgn5+Sk8erqb7vgq5SBLYF7kBv+Pb4rmsGnBOQ4NR?= =?us-ascii?q?UBUHaD9OSn0b3j4VX5QLJXjv0qiqXZsI7VJcAcpqOhBg9az54v6xe5Dzi4zN?= =?us-ascii?q?QVhWcLIE9HdR6dkoTkNVDDLOr7APuimVihnjlmy+jDPrL7A5XNKnbDkK3mfb?= =?us-ascii?q?Z480Nc0AozzdFb55JVErEBOOz8VlX/tdPCFB85NBW0w/vmCNpjzIMeQnmCAr?= =?us-ascii?q?SaMKLSt1+H+P4vL/OXa4ALoDr9MeQq5+byjX8lnl8QZayp0oELZ3CiGfRrOE?= =?us-ascii?q?GZYXvqgtccHmYGpw8+TO3yiF2ZSzJTYGyyX60k7DEhFI2mFZvDRpyqgLGZ3y?= =?us-ascii?q?e0AINWZmFACl+XCnrobZuLVOoMaC2IPs9tiCALVb+kS4U5zxGhqBf6y6Z7Lu?= =?us-ascii?q?rT4iAYuo/s28Ns6+3Ljx4y6SB7D8SD3GGWVGx0hWQIRyIs3K9jv0N8xE2M0b?= =?us-ascii?q?JmjPBCEtxT/fxJAU8GMsuW6uVxCt3wEj2HNu2OWketQdTsSWU0R9krxPcKYk?= =?us-ascii?q?BgC5CnjwjYmS2wDOlR35+GGp0yuojB0mTtIctngyLF2bcgiVMOWMZDNWS6wK?= =?us-ascii?q?V48l6AKZTOlhChl6eudLwE0Wby/X2E1HePsVtDGFpoUaTBXGgHaw3JpM7+/1?= =?us-ascii?q?7DQqW1Ia8kIw1M1YiIJ/0ZOZXSkVxaSaK7a5zlaGWrljL1XE7Qyw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BjAABw+q1e/yFRiNllGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFHgiqBQiEShEyJAYgPm14LAQEBAQEBAQE?= =?us-ascii?q?BCCwBAgQBAYREAoItJzgTAgMBAQEDAgUBAQYBAQEBAQEEBAFsBAEBBwqEUSE?= =?us-ascii?q?BAwEBBQoBQ4I7KQGDDAEBAQECASMzIxAIAxgCAiYCAlcGAYYVJLIndoEyhVG?= =?us-ascii?q?DdYFAgQ4qjFOBTD+EIT6EJYM7gmAEjiyKW5lCB4JJfwSXCh2dGy2EUIsTmQO?= =?us-ascii?q?EPYFpIoFWbYM9TyWQThcVjhJCZgIGCAEBAwl0CBOLT4JFAQE?= X-IPAS-Result: =?us-ascii?q?A2BjAABw+q1e/yFRiNllGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFHgiqBQiEShEyJAYgPm14LAQEBAQEBAQEBCCwBAgQBAYREA?= =?us-ascii?q?oItJzgTAgMBAQEDAgUBAQYBAQEBAQEEBAFsBAEBBwqEUSEBAwEBBQoBQ4I7K?= =?us-ascii?q?QGDDAEBAQECASMzIxAIAxgCAiYCAlcGAYYVJLIndoEyhVGDdYFAgQ4qjFOBT?= =?us-ascii?q?D+EIT6EJYM7gmAEjiyKW5lCB4JJfwSXCh2dGy2EUIsTmQOEPYFpIoFWbYM9T?= =?us-ascii?q?yWQThcVjhJCZgIGCAEBAwl0CBOLT4JFAQE?= Received: from 33.81-136-217.adsl-dyn.isp.belgacom.be (HELO md) ([217.136.81.33]) by relay.skynet.be with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 03 May 2020 01:01:27 +0200 Message-ID: <6dd0b78d43594ff851005a389e4a1579df546c51.camel@skynet.be> Subject: Re: [PUSHED/OBVIOUS] Remove gdb-gdb.gdb breakpoint on disappeared function info_command. From: Philippe Waroquiers To: "Maciej W. Rozycki" , Kevin Buettner Cc: Philippe Waroquiers via Gdb-patches Date: Sun, 03 May 2020 01:01:26 +0200 In-Reply-To: References: <20200501145451.20119-1-philippe.waroquiers@skynet.be> <20200501210229.5cb3950d@f31-4.lan> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Sat, 02 May 2020 23:01:31 -0000 On Sat, 2020-05-02 at 22:19 +0100, Maciej W. Rozycki wrote: > On Fri, 1 May 2020, Kevin Buettner via Gdb-patches wrote: > > > I couldn't find any clue from the ChangeLog entries about why that > > break command was put into the .gdbinit file. It might be possible to > > figure out more precisely when it was introduced, but I didn't attempt > > this. I doubt that earlier imports would have any additional useful > > info not already in the ChangeLog entries that I did examine. > > Hmm, I'm quite badly surprised to see this feature go, and I do hope it > has been functionally (and hopefully transparently) replaced with whatever > replaced `info_command'. Neither Tom nor myself we understood the idea (and saw no description) and as it was broken, it was deemed appropriate to just remove the breakpoint command from gdb-gdb.gdb. Sorry if this removal was a bad idea and inappropriate for PUSHED/OBVIOUS rule. > > Its use was quite obvious to anyone who actually debugged GDB from time > to time: it was there so that you could break from the debuggee GDB into > the debugger GDB with the use of the `info' command (with no arguments), > as obviously using signals like SIGINT for that was quite problematic. I > used to use this feature regularly, up until the last time a couple months > back when I switched to non-GDB work. I do limited GDB debugging, but was not aware of this feature. I am not sure to understand the problem: C-c works for me to interrupt GDB, and the top GDB gets back the control (I typically launch top-gdb separately and attach to the inferior GDB). Can you explain more in details the problem this was solving ? > > So what's the current mechanism to do that? I do hope to have it the > next time I poke at GDB. If something done in the inferior GDB must trigger the top GDB to regain control, we could add a specific dummy command e.g. maintenance wake-up-top-gdb and then have the breakpoint put on the wake_up_top_gdb_command function implementing this dummy command. Philippe