A question was raised today on the Libera IRC instance where a user couldn't understand the error raised by the list command. While the original user never replied, it was mentioned that a possibly confusing UX would happen in the following situation: While debugging a file close to its end, for instance the following: int main () { return 0; } starting the inferior, then trying the command list twice we get the following session: (gdb) list 1 int main(){ 2 return 0; 3 } (gdb) Line number 4 out of range; t.cc has 3 lines. With this session, the error is pretty easy to understand, but if a user is in a more complex session, having used "list" then run multiple other commands, to a point where the user would like to see the current source location again, they would get the error. In my opinion, the ideal solution is that GDB should not continue listing the program if the previous command was not "list", but reprint the current context instead. If that isn't possible, adding a message like "end of file was reached. Printing current context again" if there was no argument given to the command "list" sounds like a decent work-around.
The master branch has been updated by Bruno Larsen <blarsen@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f52625f1f29a87e94aa9d40e1b76be2d0ecedc10 commit f52625f1f29a87e94aa9d40e1b76be2d0ecedc10 Author: Bruno Larsen <blarsen@redhat.com> Date: Thu Jun 15 11:17:07 2023 +0200 gdb/cli: Improve UX when using list with no args When using "list" with no arguments, GDB will first print the lines around where the inferior is stopped, then print the next N lines until reaching the end of file, at which point it warns the user "Line X out of range, file Y only has X-1 lines.". This is usually desirable, but if the user can no longer see the original line, they may have forgotten the current line or that a list command was used at all, making GDB's error message look cryptic. It was reported in bugzilla as PR cli/30497. This commit improves the user experience by changing the behavior of "list" slightly when a user passes no arguments. It now prints that the end of the file has been reached and recommends that the user use the command "list ." instead. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
That commit fixes it