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

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

[Philippe Waroquiers]

The function info_command has disappeared, so this breakpoint does not
work anymore.
"info_command" was a function for the prefix command "info",
giving the list of "info" subcommands.
It is not very clear what the removed breakpoint and its associated
command list was supposed to do.

Removed and pushed as obvious, after discussion with Tom.
---
 gdb/ChangeLog      | 4 ++++
 gdb/gdb-gdb.gdb.in | 6 ------
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 4f3b2680bb..ee4f3a74c0 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,7 @@
+2020-05-01  Philippe Waroquiers  <philippe.waroquiers@skynet.be>
+	* gdb-gdb.gdb-in: Remove breakpoint on disappeared function
+	info_command.
+
 2020-04-30  Kamil Rytarowski  <n54@gmx.com>
 
 	* nbsd-nat.c (nbsd_enable_proc_events)
diff --git a/gdb/gdb-gdb.gdb.in b/gdb/gdb-gdb.gdb.in
index 05a38b2670..b647445e8c 100644
--- a/gdb/gdb-gdb.gdb.in
+++ b/gdb/gdb-gdb.gdb.in
@@ -7,12 +7,6 @@ if !$gdb_init_done
 
   b internal_error
 
-  b info_command
-  commands
-    silent
-    return
-  end
-
   dir @srcdir@/../libiberty
   dir @srcdir@/../bfd
   dir @srcdir@
-- 
2.20.1

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

[Kevin Buettner]

On Fri,  1 May 2020 16:54:51 +0200
Philippe Waroquiers via Gdb-patches <gdb-patches@sourceware.org> wrote:

> The function info_command has disappeared, so this breakpoint does not
> work anymore.
> "info_command" was a function for the prefix command "info",
> giving the list of "info" subcommands.
> It is not very clear what the removed breakpoint and its associated
> command list was supposed to do.
> 
> Removed and pushed as obvious, after discussion with Tom.

Thanks for doing this.

I spent a few minutes looking at this.  It was apparently introduced
into the CVS repository by Stan Shebs on 1999-04-16.  The patch in
question is massive, nearly a million lines long.  A bunch of
ChangeLog files are imported.  Actually, it seems likely that the
entirety of the GDB sources was in this import.  The earliest
ChangeLog entry is June 28, 1998 and the latest is dated about a week
prior to Stan's commit.  The commit message was "Initial creation of
sourceware repository".  (There are a number of commits which use this
same message.)

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.

Kevin

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

[Maciej W. Rozycki]

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'.

 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.

 So what's the current mechanism to do that?  I do hope to have it the 
next time I poke at GDB.

 NB I fixed the mess from the `From' rewrite and cc-ed Philippe back 
manually.

  Maciej

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

[Philippe Waroquiers]

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

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

[Kevin Buettner]

On Sun, 03 May 2020 01:01:26 +0200
Philippe Waroquiers <philippe.waroquiers@skynet.be> wrote:

> On Sat, 2020-05-02 at 22:19 +0100, Maciej W. Rozycki wrote:
>
> >  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).

FWIW, I also use Ctrl-C do get back to the top GDB.

I'd also like to understand the use case when this is problematic.

Kevin

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

[Maciej W. Rozycki]

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

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

[Simon Marchi]

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

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

[Pedro Alves]

On 5/3/20 1:13 AM, Maciej W. Rozycki wrote:

>  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.

Exactly.  I've used this feature in scenarios like you describe.  I'm
also surprised people weren't aware of the feature, and would like it
restored somehow.

> 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.

Thanks for finding it.

Pedro Alves

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

[Philippe Waroquiers]

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

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

[Tom Tromey]

>>>>> "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes:

Maciej>  Its use was quite obvious to anyone who actually debugged GDB from time 
Maciej> to time:

What was the point of the "return"?

Maciej>  So what's the current mechanism to do that?  I do hope to have it the 
Maciej> next time I poke at GDB.

You can break in "do_prefix_cmd".

Tom

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

[Philippe Waroquiers]

On Sun, 2020-05-03 at 11:17 -0600, Tom Tromey wrote:
> > > > > > "Maciej" == Maciej W Rozycki <macro@linux-mips.org> writes:
> 
> Maciej>  Its use was quite obvious to anyone who actually debugged GDB from time 
> Maciej> to time:
> 
> What was the point of the "return"?
As I understand, the idea of "info"/"i" was just to have the top-gdb
regaining control.  The return avoids the (long) output of "info"

> 
> Maciej>  So what's the current mechanism to do that?  I do hope to have it the 
> Maciej> next time I poke at GDB.
> 
> You can break in "do_prefix_cmd".
But that will break on all commands showing a list, not only on "info".

Philippe

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

[Tom Tromey]

>> What was the point of the "return"?

Philippe> As I understand, the idea of "info"/"i" was just to have the top-gdb
Philippe> regaining control.  The return avoids the (long) output of "info"

Ok, that makes sense.  Thanks.

>> You can break in "do_prefix_cmd".
Philippe> But that will break on all commands showing a list, not only on "info".

Yeah.  I'll restore info_command soon.

Tom