Re: [PATCH 1/2 version 3] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

Pedro Alves
2023-01-24T18:48:40Z

On 2023-01-24 3:53 p.m., Tom de Vries wrote:

> On 1/23/23 20:17, Pedro Alves wrote:
>> I'd think this was on purpose.  Note that next/step/reverse-{next/step} are line-oriented
>> stepping commands, they step/next until the previous/next line.  While "finish" is described
>> as undoing the_function call_.
>>
>> The manual says:
>>
>>   reverse-finish
>>   Just as the finish command takes you to the point where the current function returns,
>>   reverse-finish takes you to the point where it was called. Instead of ending up at the end of
>>   the current function invocation, you end up at the beginning.
>
> As well as:
> ...
> finish
> Continue running until just after function in the selected stack frame returns. Print the returned value (if any). This command can be abbreviated as fin.
> ...
>
> It's only now that you mention the non-line nature of finish/reverse-finish that I realize that that is the case.  So I suppose the docs could be a bit more explicit about this aspect.

I guess.

>
> I suppose an intuitive way to make available the two approaches (so without the user losing options) would be to introduce finishi next to finish and reverse-finishi next to finish, with the new commands retaining the current functionality and the old ones being adjusted to respect line boundaries.  But having the commands change behaviour is likely to cause confusion (well, assuming users notice the difference in the first place), so I'm not sure if that's a good idea.

They sure would notice a difference. Say for example, a source line like:

func1 (func2 (func3 ())));

and if you break in func3, and then do "finish", you expect that "step" steps into func2, while "next" would move to the next line.

If you changed finish to be line-oriented, then a "finish" while inside "func3" would either step over the whole "func1" call line instead,
or step into func2, depending on how you implement it. Regardless, it'd be a noticeable change, and I think a bad one.
Also, it complicates where we print the return value, as we would no longer present the stop at the instruction where we are able
to retrieve it.