Re: [PUSHED/OBVIOUS] Remove gdb-gdb.gdb breakpoint on disappeared function info_command.

[Simon Marchi <simark@simark.ca>]

On 2020-05-02 8:13 p.m., Maciej W. Rozycki wrote:
> 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 <gdb@fsf.org>
> 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 <jkingdon@engr.sgi.com>
> Date:   Tue Apr 27 23:00:39 1993 +0000
> 
> and then removed from `gdb/README' with:
> 
> commit 804d23f31dde2451e86bbafc7b2ee6743717ca94
> Author: John Gilmore <gnu@cygnus>
> 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 <shebs@codesourcery.com>
> Date:   Mon Sep 16 18:00:34 2013 +0000
> 
> so we have removed that piece of documentation from our repo, however as 
> per: <https://sourceware.org/ml/gdb-patches/2013-08/msg00855.html> it has 
> been moved to our wiki and the feature of `info' is still mentioned here: 
> <https://sourceware.org/gdb/wiki/Internals%20Debugging-GDB-with-itself>.
> 
>  So it looks like we've actually removed a documented feature.
> 
>   Maciej
> 

I really don't mind adding back this feature, especially if some folks are used
to it.  If you don't use it, it doesn't hurt you.

But I think it all shows the importance of documenting the intent along with the
code, don't be cheap on comments :).

Simon