This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
What should "finish" do?
- To: gdb at sourceware dot cygnus dot com
- Subject: What should "finish" do?
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Tue, 2 May 2000 16:44:43 -0700
I recently posted the following RFA to gdb-patches:
http://sourceware.cygnus.com/ml/gdb-patches/2000-04/msg00465.html
This was a change to the testsuite to cause certain tests to pass
for the IA-64 which (seemed to me) to be incorrectly failing due
to a difference in the way the compiler generated code for the IA-64
architecture.
Fernando approved my patch, but added the following note:
I don't necessarily agree with the gdb behavior. IMO finish a
call does not mean simply return, but really finish whatever is
related to the call, which would include restoring the global
pointer and stop at the next line. Remember, gdb is a source
level debugger, so a "call" to the user is the source line that
makes the call -- it should complete with a "finish" (it is not
"finishi", making the parallel to stepi and nexti).
After reading Fernando's note, I'm left wondering if the correct
course of action is to withdraw my patch and work on fixing gdb
instead.
But before doing either, I decided to ask for opinions on what "finish"
should do.
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.
Note that stopping at the next line is not a sensible option because
if you finish out of g() in f(g()), it is an error to stop execution
at the next line. I.e, you want to have the opportunity to step into
f().
Opinions?
Kevin