public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Update help of the "frame" command
@ 2017-01-06 15:16 Simon Marchi
  2017-01-06 16:25 ` Luis Machado
  2017-01-09 17:27 ` Yao Qi
  0 siblings, 2 replies; 9+ messages in thread
From: Simon Marchi @ 2017-01-06 15:16 UTC (permalink / raw)
  To: gdb-patches; +Cc: Simon Marchi

The help message of the "frame" command states that nothing is printed
if the command is executed from the command file or user-defined
command.  My testing leads me to think that this is not true (at least
today).

  (gdb) bt
  #0  bar (n=17) at test.c:9
  #1  0x00000000004006e0 in foo (v=17) at test.c:13
  #2  0x00000000004006f0 in main () at test.c:21
  (gdb) frame
  #0  bar (n=17) at test.c:9
  9	    baz(n);
  (gdb) define foo
  Type commands for definition of "foo".
  End with a line saying just "end".
  >frame 1
  >end
  (gdb) foo
  #1  0x00000000004006e0 in foo (v=17) at test.c:13
  13	    bar(v);

This patch simply removes that bit from the help message.  I didn't find
anything corresponding to this in the documentation that needs to be
fixed.

gdb/ChangeLog:

	* stack.c (_initialize_stack): Update "frame" command help message.
---
 gdb/stack.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/gdb/stack.c b/gdb/stack.c
index 64224d0aad..201a358833 100644
--- a/gdb/stack.c
+++ b/gdb/stack.c
@@ -2666,9 +2666,7 @@ This is useful in command scripts."));
 Select and print a stack frame.\nWith no argument, \
 print the selected stack frame.  (See also \"info frame\").\n\
 An argument specifies the frame to select.\n\
-It can be a stack frame number or the address of the frame.\n\
-With argument, nothing is printed if input is coming from\n\
-a command file or a user-defined command."));
+It can be a stack frame number or the address of the frame.\n"));
 
   add_com_alias ("f", "frame", class_stack, 1);
 
-- 
2.11.0

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-06 15:16 [PATCH] Update help of the "frame" command Simon Marchi
@ 2017-01-06 16:25 ` Luis Machado
  2017-01-06 16:28   ` Simon Marchi
  2017-01-09 17:27 ` Yao Qi
  1 sibling, 1 reply; 9+ messages in thread
From: Luis Machado @ 2017-01-06 16:25 UTC (permalink / raw)
  To: Simon Marchi, gdb-patches

On 01/06/2017 09:16 AM, Simon Marchi wrote:
> The help message of the "frame" command states that nothing is printed
> if the command is executed from the command file or user-defined
> command.  My testing leads me to think that this is not true (at least
> today).
>
>   (gdb) bt
>   #0  bar (n=17) at test.c:9
>   #1  0x00000000004006e0 in foo (v=17) at test.c:13
>   #2  0x00000000004006f0 in main () at test.c:21
>   (gdb) frame
>   #0  bar (n=17) at test.c:9
>   9	    baz(n);
>   (gdb) define foo
>   Type commands for definition of "foo".
>   End with a line saying just "end".
>   >frame 1
>   >end
>   (gdb) foo
>   #1  0x00000000004006e0 in foo (v=17) at test.c:13
>   13	    bar(v);
>
> This patch simply removes that bit from the help message.  I didn't find
> anything corresponding to this in the documentation that needs to be
> fixed.
>
> gdb/ChangeLog:
>
> 	* stack.c (_initialize_stack): Update "frame" command help message.
> ---
>  gdb/stack.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/gdb/stack.c b/gdb/stack.c
> index 64224d0aad..201a358833 100644
> --- a/gdb/stack.c
> +++ b/gdb/stack.c
> @@ -2666,9 +2666,7 @@ This is useful in command scripts."));
>  Select and print a stack frame.\nWith no argument, \
>  print the selected stack frame.  (See also \"info frame\").\n\
>  An argument specifies the frame to select.\n\
> -It can be a stack frame number or the address of the frame.\n\
> -With argument, nothing is printed if input is coming from\n\
> -a command file or a user-defined command."));
> +It can be a stack frame number or the address of the frame.\n"));
>
>    add_com_alias ("f", "frame", class_stack, 1);
>
>

Sounds reasonable to me. I ran into other help text block 
inconsistencies. It looks like there is potential for more corrections 
in that area.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-06 16:25 ` Luis Machado
@ 2017-01-06 16:28   ` Simon Marchi
  2017-01-06 16:30     ` Luis Machado
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Marchi @ 2017-01-06 16:28 UTC (permalink / raw)
  To: Luis Machado; +Cc: Simon Marchi, gdb-patches

On 2017-01-06 11:25, Luis Machado wrote:
> Sounds reasonable to me. I ran into other help text block
> inconsistencies. It looks like there is potential for more corrections
> in that area.

If you want to point them out, I can take a look and try to make 
patches.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-06 16:28   ` Simon Marchi
@ 2017-01-06 16:30     ` Luis Machado
  0 siblings, 0 replies; 9+ messages in thread
From: Luis Machado @ 2017-01-06 16:30 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Simon Marchi, gdb-patches

On 01/06/2017 10:28 AM, Simon Marchi wrote:
> On 2017-01-06 11:25, Luis Machado wrote:
>> Sounds reasonable to me. I ran into other help text block
>> inconsistencies. It looks like there is potential for more corrections
>> in that area.
>
> If you want to point them out, I can take a look and try to make patches.

I'm about to send an improvement to the "load" command, but basically i 
noticed we are lacking proper usage information in some commands. I 
don't have a list off the top of my head though.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-06 15:16 [PATCH] Update help of the "frame" command Simon Marchi
  2017-01-06 16:25 ` Luis Machado
@ 2017-01-09 17:27 ` Yao Qi
  2017-01-09 18:13   ` Simon Marchi
  1 sibling, 1 reply; 9+ messages in thread
From: Yao Qi @ 2017-01-09 17:27 UTC (permalink / raw)
  To: Simon Marchi; +Cc: gdb-patches

On 17-01-06 10:16:10, Simon Marchi wrote:
> @@ -2666,9 +2666,7 @@ This is useful in command scripts."));
>  Select and print a stack frame.\nWith no argument, \
>  print the selected stack frame.  (See also \"info frame\").\n\
>  An argument specifies the frame to select.\n\
> -It can be a stack frame number or the address of the frame.\n\
> -With argument, nothing is printed if input is coming from\n\
> -a command file or a user-defined command."));
> +It can be a stack frame number or the address of the frame.\n"));
>  

These two lines were added many years ago,

c906108c (Stan Shebs       1999-04-16 01:35:26 +0000 2632) It can be a stack frame number or the address of the frame.\n\
c906108c (Stan Shebs       1999-04-16 01:35:26 +0000 2633) With argument, nothing is printed if input is coming from\n\

Did you do some archaeology to see how GDB did at that time? and then
we may know these help doc is a leftover of some changes.  If we can
find them, we are confident to remove these doc.  I spent 30 minutes
on c906108c, but didn't find any evidence.

-- 
Yao (齐尧)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-09 17:27 ` Yao Qi
@ 2017-01-09 18:13   ` Simon Marchi
  2017-01-10 11:00     ` Yao Qi
  0 siblings, 1 reply; 9+ messages in thread
From: Simon Marchi @ 2017-01-09 18:13 UTC (permalink / raw)
  To: Yao Qi; +Cc: Simon Marchi, gdb-patches

On 2017-01-09 12:27, Yao Qi wrote:
> These two lines were added many years ago,
> 
> c906108c (Stan Shebs       1999-04-16 01:35:26 +0000 2632) It can be a
> stack frame number or the address of the frame.\n\
> c906108c (Stan Shebs       1999-04-16 01:35:26 +0000 2633) With
> argument, nothing is printed if input is coming from\n\
> 
> Did you do some archaeology to see how GDB did at that time? and then
> we may know these help doc is a leftover of some changes.  If we can
> find them, we are confident to remove these doc.  I spent 30 minutes
> on c906108c, but didn't find any evidence.

Indeed, it's the commit "Initial creation of sourceware repository".  I 
checked out that commit and looked at the code, but couldn't find 
anything that would suggest that the output of the frame command would 
not be printed when it's executing in a script or user command.

I went earlier using the old tarballs on the website [1], and found that 
in old gdb's, there was code like this:

  965   if (!from_tty)
  966     return;
  967
  968   print_stack_frame (selected_frame, selected_frame_level, 1);

The (!from_tty) check disappeared in gdb 4.3.  I think it's this change:

  873 Thu Oct 24 09:33:44 1991  John Gilmore  (gnu at cygnus.com)
  874
  875         * stack.c (frame_command):  Always print.  Use new
  876         frame_select_command to select a frame without printing.

after that, the frame_command function becomes simply:

  974 static void
  975 frame_command (level_exp, from_tty)
  976      char *level_exp;
  977      int from_tty;
  978 {
  979   select_frame_command (level_exp, from_tty);
  980   print_stack_frame (selected_frame, selected_frame_level, 1);
  981 }

So I think it's safe.

Side-question, is there a git repo somewhere with all these old gdb 
versions, those that predate what's in the current git tree?  It would 
be useful to have a repo with one commit per version.  Here I had to 
download many tarballs and bisect manually, but if they had been in a 
repo it would have been trivial.  If it doesn't exist yet, I think I'll 
do it.

[1] ftp://sourceware.org/pub/gdb/old-releases/

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-09 18:13   ` Simon Marchi
@ 2017-01-10 11:00     ` Yao Qi
  2017-01-10 15:20       ` Simon Marchi
  2017-01-10 16:01       ` Pedro Alves
  0 siblings, 2 replies; 9+ messages in thread
From: Yao Qi @ 2017-01-10 11:00 UTC (permalink / raw)
  To: Simon Marchi; +Cc: Simon Marchi, gdb-patches

On 17-01-09 13:13:42, Simon Marchi wrote:
> Indeed, it's the commit "Initial creation of sourceware repository".
> I checked out that commit and looked at the code, but couldn't find
> anything that would suggest that the output of the frame command
> would not be printed when it's executing in a script or user
> command.
> 
> I went earlier using the old tarballs on the website [1], and found
> that in old gdb's, there was code like this:
> 
>  965   if (!from_tty)
>  966     return;
>  967
>  968   print_stack_frame (selected_frame, selected_frame_level, 1);
> 
> The (!from_tty) check disappeared in gdb 4.3.  I think it's this change:
> 
>  873 Thu Oct 24 09:33:44 1991  John Gilmore  (gnu at cygnus.com)
>  874
>  875         * stack.c (frame_command):  Always print.  Use new
>  876         frame_select_command to select a frame without printing.
> 
> after that, the frame_command function becomes simply:
> 
>  974 static void
>  975 frame_command (level_exp, from_tty)
>  976      char *level_exp;
>  977      int from_tty;
>  978 {
>  979   select_frame_command (level_exp, from_tty);
>  980   print_stack_frame (selected_frame, selected_frame_level, 1);
>  981 }
> 
> So I think it's safe.

Thanks for digging it up.  Patch is OK.

> 
> Side-question, is there a git repo somewhere with all these old gdb
> versions, those that predate what's in the current git tree?  It
> would be useful to have a repo with one commit per version.  Here I
> had to download many tarballs and bisect manually, but if they had
> been in a repo it would have been trivial.  If it doesn't exist yet,
> I think I'll do it.
> 
> [1] ftp://sourceware.org/pub/gdb/old-releases/

They were imported into the git repository.  The change you found
above is in b00771232fab861fb31e42dfd5f6643ba1b43cc9

-- 
Yao (齐尧)

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-10 11:00     ` Yao Qi
@ 2017-01-10 15:20       ` Simon Marchi
  2017-01-10 16:01       ` Pedro Alves
  1 sibling, 0 replies; 9+ messages in thread
From: Simon Marchi @ 2017-01-10 15:20 UTC (permalink / raw)
  To: Yao Qi, Simon Marchi; +Cc: gdb-patches

On 17-01-10 06:00 AM, Yao Qi wrote:
> On 17-01-09 13:13:42, Simon Marchi wrote:
>> Indeed, it's the commit "Initial creation of sourceware repository".
>> I checked out that commit and looked at the code, but couldn't find
>> anything that would suggest that the output of the frame command
>> would not be printed when it's executing in a script or user
>> command.
>>
>> I went earlier using the old tarballs on the website [1], and found
>> that in old gdb's, there was code like this:
>>
>>  965   if (!from_tty)
>>  966     return;
>>  967
>>  968   print_stack_frame (selected_frame, selected_frame_level, 1);
>>
>> The (!from_tty) check disappeared in gdb 4.3.  I think it's this change:
>>
>>  873 Thu Oct 24 09:33:44 1991  John Gilmore  (gnu at cygnus.com)
>>  874
>>  875         * stack.c (frame_command):  Always print.  Use new
>>  876         frame_select_command to select a frame without printing.
>>
>> after that, the frame_command function becomes simply:
>>
>>  974 static void
>>  975 frame_command (level_exp, from_tty)
>>  976      char *level_exp;
>>  977      int from_tty;
>>  978 {
>>  979   select_frame_command (level_exp, from_tty);
>>  980   print_stack_frame (selected_frame, selected_frame_level, 1);
>>  981 }
>>
>> So I think it's safe.
> 
> Thanks for digging it up.  Patch is OK.
> 
>>
>> Side-question, is there a git repo somewhere with all these old gdb
>> versions, those that predate what's in the current git tree?  It
>> would be useful to have a repo with one commit per version.  Here I
>> had to download many tarballs and bisect manually, but if they had
>> been in a repo it would have been trivial.  If it doesn't exist yet,
>> I think I'll do it.
>>
>> [1] ftp://sourceware.org/pub/gdb/old-releases/
> 
> They were imported into the git repository.  The change you found
> above is in b00771232fab861fb31e42dfd5f6643ba1b43cc9
> 

Ah ok, it seems like there is a disconnect at "Initial creation of sourceware repository",
my blame tool doesn't allow me to go past that.  But indeed, if I manually checkout a
previous commit I see the older versions.

I added a reference to that commit in my commit log and pushed the patch, thanks.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] Update help of the "frame" command
  2017-01-10 11:00     ` Yao Qi
  2017-01-10 15:20       ` Simon Marchi
@ 2017-01-10 16:01       ` Pedro Alves
  1 sibling, 0 replies; 9+ messages in thread
From: Pedro Alves @ 2017-01-10 16:01 UTC (permalink / raw)
  To: Yao Qi, Simon Marchi; +Cc: Simon Marchi, gdb-patches

On 01/10/2017 11:00 AM, Yao Qi wrote:
> On 17-01-09 13:13:42, Simon Marchi wrote:

>> Side-question, is there a git repo somewhere with all these old gdb
>> versions, those that predate what's in the current git tree?  It
>> would be useful to have a repo with one commit per version.  Here I
>> had to download many tarballs and bisect manually, but if they had
>> been in a repo it would have been trivial.  If it doesn't exist yet,
>> I think I'll do it.
>>
>> [1] ftp://sourceware.org/pub/gdb/old-releases/
> 
> They were imported into the git repository.  The change you found
> above is in b00771232fab861fb31e42dfd5f6643ba1b43cc9
> 

Yes, they were imported from here:

 https://github.com/palves/gdb-old-releases

The git history around the initial CVS import is quite
annoying, since there were a series of commits that added
the whole of gdb, then removed it, then re-added it, etc.
I think there are ways in git nowadays to tell (local) git to
see through a range of commits, so effectively
"virtually squash" those deletions as if they never existed,
but I never investigated exactly how to do it.  If someone pulls
that off, I think it'd be great.

Thanks,
Pedro Alves

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-01-10 16:01 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-06 15:16 [PATCH] Update help of the "frame" command Simon Marchi
2017-01-06 16:25 ` Luis Machado
2017-01-06 16:28   ` Simon Marchi
2017-01-06 16:30     ` Luis Machado
2017-01-09 17:27 ` Yao Qi
2017-01-09 18:13   ` Simon Marchi
2017-01-10 11:00     ` Yao Qi
2017-01-10 15:20       ` Simon Marchi
2017-01-10 16:01       ` Pedro Alves

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).