help-gnu-emacs
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]