gdb: fix forward and reverse search commands to match documentation
The forward-search and reverse-search commands were broken by this
commit:
commit a75cd9a2c129dfc086cbe570ef9cff9b84570bbd
Date: Thu Nov 14 16:11:15 2019 -0700
Add observable to watch current source symtab
while builds on the work in this commit:
commit 1dd588507782591478882a891f64945af9e2b86c
Date: Thu Aug 1 09:34:40 2019 -0600
Make current_source_* per-program-space
both of these commits went into GDB 10.
The documentation for these commands is pretty clear:
'forward-search REGEXP'
'search REGEXP'
The command 'forward-search REGEXP' checks each line, starting with
the one following the last line listed, for a match for REGEXP. It
lists the line that is found. You can use the synonym 'search
REGEXP' or abbreviate the command name as 'fo'.
'reverse-search REGEXP'
The command 'reverse-search REGEXP' checks each line, starting with
the one before the last line listed and going backward, for a match
for REGEXP. It lists the line that is found. You can abbreviate
this command as 'rev'.
Both searches should start searching based on the last line listed.
But currently:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) forward-search Line
4 /* Line 4 */
(gdb)
This should have found line 11. And for reverse-search:
(gdb) list 3
1 int
2 main (void)
3 {
4 /* Line 4 */
5 /* Line 5 */
6 /* Line 6 */
7 /* Line 7 */
8 /* Line 8 */
9 /* Line 9 */
10 /* Line 10 */
(gdb) reverse-search Line
Expression not found
(gdb)
The reverse-search should have returned line 9.
This new behaviour started with the above commits in GDB 10. On GDB 9
we see behaviour that matches the documentation.
Where the forward and reverse searches start from is controlled by a
global, last_line_listed, found in source.c.
Before commit 1dd588507782, in print_source_lines_base, the
last_line_listed variable was updated as each source line was printed,
and it was updated with the current line being printed.
After commit 1dd588507782, the current symtab and line are moved into
a current_source_location object, but the symtab and line member
variables are public. The last_line_listed is still set based on the
value held in the current_source_location object, and this object is
updated each time around the source printing loop. So despite the
restructure, the logic, and behaviour, is unchanged.
After commit a75cd9a2c129, the member variables of
current_source_location are now private. The source printing loop in
print_source_lines_base uses a local variable, new_lineno, to track
the current source line number, and updates the
current_source_location at the end of print_source_lines_base.
However, last_line_listed is still updated inside the loop, using the
original line value within current_source_location, which is no longer
being updated each time around the loop.
As a result, last_line_listed is now just the first line listed!
This didn't show up in testing because, as far as I can tell, the
last_line_listed is _only_ used for forward and reverse searching, and
the testing for these commands is minimal.
In this commit I move the setting of last_line_listed outside of the
source printing loop, this only needs to be updated once, when we have
finished printing the source lines.
I've also done a couple of other cleanups in the same area, I moved
'buf' a local variable into the most inner scope where it is required,
and I converted the 'while' loop into a 'for' loop, moving the
increment out of the loop body.
There's now a test which does some more detailed checks of the forward
and reverse search commands.
Approved-By: Tom Tromey <tom@tromey.com>
3 files changed
