This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Update help of the "frame" command

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]