From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailsec114.isp.belgacom.be (mailsec114.isp.belgacom.be [195.238.20.110]) by sourceware.org (Postfix) with ESMTPS id 6C6583851C1C for ; Sun, 3 May 2020 12:45:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6C6583851C1C IronPort-SDR: 14hA4ZuNVkQ9oCAlWUPW/sZ5di5iAFRL0+9Xhe/SsR3A6S0ovwxXfX0OSfMEG3Ne/2iFEvZJ7U uUXplKyuRPF9i/xd8Kw1Efruj/QkyueX5vZef3vu5158UOz8PXhiypMIPuCHYf6HLSiMp4Ma5t Pt6yCSjpGaCBl7GCAXp5g4xa5vCLXfJ/FnEU+yeTLt12wK1h19ndhI1b9eH4cETEK7M2Lq5v+R zjzxQwmeT0PYVnQ+aomUir73KXQFBiRA9juqGKT5b4hu1DFRA8N7F7ZLfFyDuD5Scl5YcBfhVg d9M= IronPort-PHdr: =?us-ascii?q?9a23=3A2C0FTBYj/0TKf2dUdalaho3/LSx+4OfEezUN45?= =?us-ascii?q?9isYplN5qZpsy4Zh7h7PlgxGXEQZ/co6odzbaP7ua/AyddvN6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLBi6twfcutcZjYZiKqs61w?= =?us-ascii?q?fErGZPd+lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2?= =?us-ascii?q?466svrtQLeTQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUj?= =?us-ascii?q?ms86tnVBnlgzocOjUn7G/YlNB/jKNDoBKguRN/xZLUYJqIP/Z6Z6/RYM8WSX?= =?us-ascii?q?ZEUstXSidPAJ6zb5EXAuQCIOhWr5fzqVUMohuwGQajCuzgxDBTi3/q36A3yf?= =?us-ascii?q?gtHR3c0QEiGd8FrXTarM/yNKcXSe271qnIzTTHb/NXwTf98JbHeQ0hrv6WR7?= =?us-ascii?q?JwdtPRyVQuFwzblFWQspHuMjSN1uQNsmib6+tgVfq3i2E5sQ1wrCKgxt0rio?= =?us-ascii?q?nQm4IVy07L9T9iwIsuPt24S056Ydi6H5tMrS2VLJV5T9okTmp1tyk01qcIto?= =?us-ascii?q?SnfCgW1psn3RjfZuSZf4SW4R/uSOmcLStkiH9neL+yiAu//0i8xuDzWce60E?= =?us-ascii?q?tHoyRBn9TSuH4AyRLe58uER/Zz/0qs2TiC2g/X5+xFJ00/iKnVK4Y5z7Iui5?= =?us-ascii?q?Yes17PEjL4lUj3lqObdVgo9vKm5unpZLjtu4WSOJVuig7kN6Qjgsm/AeMlPQ?= =?us-ascii?q?cQR2Wb4uG81KH7/U3+XbVKkuU6kqnHv5DeIsQWvqu5DBJN3oYi7RawESum3c?= =?us-ascii?q?wGkXUaLl9JYg+LgoboNl3UI/30EO2zjlqinTtzwvDJJLzhApHDLnjZl7fheK?= =?us-ascii?q?5w61ZcyAoyydBf5opUCqkfL/7pVE7+rsbYDhggMwypwuboFs991pgFVGKUAa?= =?us-ascii?q?+YMKXSvkGU5u41OOaDepcZuCzhJPg9+/7ukXg5lEcYfaazwZQXcne4E+9iI0?= =?us-ascii?q?WYZ3rsn9gAHX4Pvgo/VOzqk0eOUTlJZ3a9R6g8/C00CJq6DYffQYCgmL+B0z?= =?us-ascii?q?mlHp1XYGBJEUuBEW32eIqZW/cDcj6SLtV9nTwDULirU5Uh2g22tA/m17pnKf?= =?us-ascii?q?LZ+iIFup34zdR1//fclQ0u+jx0EcudyHqAT3pznmMVXT85wL5woEJnxVeZz6?= =?us-ascii?q?d0mftYFcZc56ABbgBvf7vVxO13CZjNHEr7ecWYQ1WnCJ3yBDg6VNUZx94Ifl?= =?us-ascii?q?Y4HtS6lVbExSX8UJEPkLnePJw19qPEx3W5GM9nzG/b1aQ7lBFyWstOMWy+nq?= =?us-ascii?q?M56AHJAJfUkkiDjI6xdrUa0TKL/mrVnjnGh11RTAMlCfaNZnsYfEaD6I2hvk?= =?us-ascii?q?4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2AMAQCmvK5e/yFRiNlmGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAUCBR4IqgUIhEoRMiQGID5l3gWcLAQEBAQEBAQEBCCw?= =?us-ascii?q?BAgQBAYREAoItJzgTAgMBAQEDAgUBAQYBAQEBAQEEBAFsBAEBBwqEUSEBAwE?= =?us-ascii?q?BBQoBQ4I7KQGDDQEFIzMjEAgDGAICJgICVwaGOrI/gTKFUYNlgUCBDiqMU4F?= =?us-ascii?q?MP4QhPoQlD4MsgmAEjiyKW5lCB4JJfwSXCh2dGy2EUKQWhD2BaSKBVm2DPU8?= =?us-ascii?q?lkHqOEkJmAgYIAQEDCXQIE4tPgkUBAQ?= X-IPAS-Result: =?us-ascii?q?A2AMAQCmvK5e/yFRiNlmGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBR4IqgUIhEoRMiQGID5l3gWcLAQEBAQEBAQEBCCwBAgQBAYREAoItJ?= =?us-ascii?q?zgTAgMBAQEDAgUBAQYBAQEBAQEEBAFsBAEBBwqEUSEBAwEBBQoBQ4I7KQGDD?= =?us-ascii?q?QEFIzMjEAgDGAICJgICVwaGOrI/gTKFUYNlgUCBDiqMU4FMP4QhPoQlD4Msg?= =?us-ascii?q?mAEjiyKW5lCB4JJfwSXCh2dGy2EUKQWhD2BaSKBVm2DPU8lkHqOEkJmAgYIA?= =?us-ascii?q?QEDCXQIE4tPgkUBAQ?= 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 14:45:50 +0200 Message-ID: <97ebcb3519e3c79f9e081ffdb786e420c893a586.camel@skynet.be> Subject: Re: [PUSHED/OBVIOUS] Remove gdb-gdb.gdb breakpoint on disappeared function info_command. From: Philippe Waroquiers To: "Maciej W. Rozycki" Cc: Kevin Buettner , Philippe Waroquiers via Gdb-patches Date: Sun, 03 May 2020 14:45:50 +0200 In-Reply-To: References: <20200501145451.20119-1-philippe.waroquiers@skynet.be> <20200501210229.5cb3950d@f31-4.lan> <6dd0b78d43594ff851005a389e4a1579df546c51.camel@skynet.be> 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=-9.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_LOW, 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: Sun, 03 May 2020 12:45:54 -0000 On Sun, 2020-05-03 at 01:13 +0100, Maciej W. Rozycki wrote: > On Sun, 3 May 2020, Philippe Waroquiers wrote: > > 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 ? > > I don't remember offhand; I do remember there were issues in some debug > scenarios with using signals, perhaps unintended delivery to the debuggee > GDB (or its debuggee), or some problems with trapping the signal in the > first place (perhaps on MinGW, where obviously we don't have a typical > *nix environment and ^C may have simply killed the outer GDB and other > signals such as SIGQUIT may not have had a way to be produced at all). > Especially as when debugging broken GDB (which is why you debug it in the > first place) you often find it in an odd state. > > In any case `info' was a clean and reliable way to break into the outer > GDB from the inner GDB's command prompt. > > > > 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. > > Ouch, that's a horrible lot of characters to type, even if we factor in > completion (which some host configurations lack, e.g. MinGW); one of the > obvious features of `info' was its brevity (especially in its `i' short > form). > > If the `info' command has been removed (why?), then I think a stub ought > to be added back, just to have this feature restored. As I understand, the purpose of the commit 0743fc83c03 was to remove (not too sure how many commands were removed but something like 100 ?) duplicated implementations of some commands. For the user, "info" without arguments works as before, but is using code common to all such prefix commands. I debugged GDB (without the 'i' break-me feature :)). In the stack trace, I see no function specific to the "info" command. So, if we want to restore this 'i' break-me feature exactly as is, it looks like something special must then be done in the code for the "info" command (like re-duplicating the code just for "info"). Alternatively, alias I = maintenance wake-up-top-gdb or alias mw = maintenance wake-up-top-gdb would make it short (but break the habits of GDB developers used to 'i' or 'info'). Philippe