This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: What should "finish" do?
- To: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Subject: Re: What should "finish" do?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 03 May 2000 18:44:37 +1000
- CC: Kevin Buettner <kevinb at cygnus dot com>, gdb at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <200005030838.KAA15151@reisser.regent.e-technik.tu-muenchen.de>
"Peter.Schauer" wrote:
>
> > 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().
>
> And we are interested in the return value of g(), which might already
> be clobbered if we stop in the next line.
> I'd favor 2) as well, but I suspect that it will add extra hair for some
> targets.
It will definitly be hard (once -O is applied). Compilers like to
forget to cleanup stack frames so walking the unwind instructions could
end up as hairy as the code that skips the prologue.
(But I agree, it is more correct).
Andrew