From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cvs.linux-mips.org (eddie.linux-mips.org [148.251.95.138]) by sourceware.org (Postfix) with ESMTP id CB0223858D32 for ; Sun, 3 May 2020 00:13:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CB0223858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-mips.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=macro@linux-mips.org Received: (from localhost user: 'macro', uid#1010) by eddie.linux-mips.org with ESMTP id S23993116AbgECANN3UCli (ORCPT ); Sun, 3 May 2020 02:13:13 +0200 Date: Sun, 3 May 2020 01:13:13 +0100 (BST) Sender: "Maciej W. Rozycki" From: "Maciej W. Rozycki" To: Philippe Waroquiers cc: Kevin Buettner , Philippe Waroquiers via Gdb-patches Subject: Re: [PUSHED/OBVIOUS] Remove gdb-gdb.gdb breakpoint on disappeared function info_command. In-Reply-To: <6dd0b78d43594ff851005a389e4a1579df546c51.camel@skynet.be> Message-ID: References: <20200501145451.20119-1-philippe.waroquiers@skynet.be> <20200501210229.5cb3950d@f31-4.lan> <6dd0b78d43594ff851005a389e4a1579df546c51.camel@skynet.be> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KHOP_HELO_FCRDNS, SPF_HELO_NONE, SPF_NONE, TXREP, UNPARSEABLE_RELAY autolearn=no 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 00:13:17 -0000 On Sun, 3 May 2020, Philippe Waroquiers 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. I'm fairly sure it was documented somewhere, but I seem unable to track it down now. Maybe it was just meant to be obvious from `.gdbinit'. I must have used this feature for some 20 years now at the very least. > Sorry if this removal was a bad idea and inappropriate for > PUSHED/OBVIOUS rule. I think it's the original commit that removed `info_command' that should have had this feature discussed. > > 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 ? 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. Also it's much older than you suggested, and comes from: commit e91b87a36830d061ef87d67be5f309e4d4ed918f Author: gdb-3.1 Date: Tue Jan 31 17:56:40 1989 +0000 gdb-3.1 -- see just the top of this commit. Ah, there it goes (from that commit) as far as the piece of documentation I have been missing has been concerned: +The "info" command, when executed without a subcommand in a gdb being +debugged by gdb, will pop you back up to the top level gdb. See +.gdbinit for more details. in `gdb/README'. It was then added to `gdb/doc/gdbint.texinfo' with: commit a5e7f259539178b69a1a371cd4aa25a1787f3995 Author: Jim Kingdon Date: Tue Apr 27 23:00:39 1993 +0000 and then removed from `gdb/README' with: commit 804d23f31dde2451e86bbafc7b2ee6743717ca94 Author: John Gilmore Date: Sun Aug 1 20:03:51 1993 +0000 Finally `gdb/doc/gdbint.texinfo' was removed in its entriety with: commit 0a7cfe2cf50b450d0cf9db16ee4bd027e08763e8 Author: Stan Shebs Date: Mon Sep 16 18:00:34 2013 +0000 so we have removed that piece of documentation from our repo, however as per: it has been moved to our wiki and the feature of `info' is still mentioned here: . So it looks like we've actually removed a documented feature. Maciej