Re: What should "finish" do?

[Jim Blandy <jimb at zwingli dot cygnus dot com>]

> As I see it, there are two sensible options:
> 
>     1) "finish" should finish executing the current function and cause
>        execution to stop when control is returned to the caller (at the
>        earliest point).
> 
>     2) "finish" should finish executing the current function and cause
>        execution to stop when control is returned to the caller, but
>        after whatever (architecture specific, perhaps even compiler
>        specific) instructions are used to restore the caller-save
>        registers.

I don't think there's any disagreement on what the behavior should be.
The `finish' command should do what you'd expect a finish to do at the
source level.  After a finish, you should be able to examine whatever
variables are in scope, in the normal way.  The real question is how
to get there.

Analyzing the code stream is processor-specific, confused by perfectly
legitimate compiler optimizations, and hairy.

One solution would be for GCC to emit debugging info explaining where
to find each variable at each PC value in the function.  That is, it
would tell GDB that the variable moves from the register to the stack
before the function call, and from the stack back to the register
after the call.  GDB would then decide where to find the variable
based on the current PC value.

Both Dwarf 2 and stabs can describe variables which live in different
locations at different points in the code.  GDB doesn't currently
parse the Dwarf 2 info; the stabs info is ugly, but we do parse it.

If GDB knew where to find the variable at all times, it could simply
check the PC after a "finish", and see that it should look on the
stack to find variables that live in caller-saves registers.