From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "David Vanderschel" Newsgroups: gmane.emacs.help Subject: Re: edebug question - context of calling function Date: Fri, 24 Oct 2003 13:41:47 -0500 Organization: hardly ever ;-) Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: References: <0tWdnZ-zD5A5zBKiRTvUqg@texas.net> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1067021367 6781 80.91.224.253 (24 Oct 2003 18:49:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2003 18:49:27 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Oct 24 20:49:25 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AD700-0001iw-00 for ; Fri, 24 Oct 2003 20:49:25 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AD6xQ-0003T1-9c for geh-help-gnu-emacs@m.gmane.org; Fri, 24 Oct 2003 14:46:44 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.texas.net!news.texas.net.POSTED!not-for-mail Original-NNTP-Posting-Date: Fri, 24 Oct 2003 13:41:41 -0500 Original-Newsgroups: gnu.emacs.help X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Original-Lines: 51 Original-X-Trace: sv3-w69mdQQGeuAJEMA+sUwo5unJRiYokMLmnKYpH6ejk4ch8FfyuQq2Of2mTb8rvLD7XZGuBZyI6RNWQ5s!55OVAIstY1ZSANKwyhwv1/kOrCnq6WLB9Ssyvpy3nYam0CmluqQkmD6sY/TC Original-X-Complaints-To: abuse@texas.net X-DMCA-Complaints-To: abuse@texas.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Original-Xref: shelby.stanford.edu gnu.emacs.help:117594 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:13526 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:13526 "Stefan Monnier" wrote in message news:... > > 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.