[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: edebug question - context of calling function
From: |
David Vanderschel |
Subject: |
Re: edebug question - context of calling function |
Date: |
Fri, 24 Oct 2003 13:41:47 -0500 |
"Stefan Monnier" <monnier@iro.umontreal.ca> wrote in message
news:<jwvu15yskro.fsf-monnier+gnu.emacs.help@vor.iro.umontreal.ca>...
> > I am familiar with other debuggers which allow you to
> > proceed up and down the stack of call frames, looking
> > at context (including location of the call in each
> > calling program) in a whole hierarchy of calling
> > functions. I just expected such capability in edebug
> > and was trying to find out how to exercise it.
> > However, I am willing to accept that the capability is
> > not there.
> I don't think edebug has that feature, although I can't think of
> any particular reason why not (as long as the calling function
> you want to look at is instrumented, of course).
I could not think of any such reason either, which is
why I was looking for the functionality. (I was
instrumenting the calling function.)
> If your calling function is byte-compiled, you can
> improve things a little by using the
> non-byte-compiled version in which case the
> backtrace will give you more than just the calling
> function's name and arguments. It won't give you
> line numbers, but you should/might be able to
> recognize the calling context enough to figure out
> which of the calls is currently active.
If the calling function has been instrumented, the
point about byte-compiling is moot. The particular
function which intiated this quest is one in which I
made rather heavy use of CL macros. The result is
fairly effective obfuscation of any recognizable
context.
I just discovered something which does help: After
the source breakpoint is hit, I can set a breakpoint
at the end of the called function (or step down to
there). Then I can step through the return to the
calling function and I _do_ wind up in the context of
the calling program. So this approach can be used
whenever it is possible to make a return from the
function which recognizes the problem - a possibility
which does exist in the situation which concerned me.
I'd still prefer to be able to get there without executing
the remainder of the called function.
Regards,
David V.