From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Rocky Bernstein Newsgroups: gmane.emacs.devel Subject: (How) can I get position information backtraces? Date: Mon, 18 Sep 2017 19:05:03 -0400 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1145ed04d638fa05597ec5c2" X-Trace: blaine.gmane.org 1505775916 21584 195.159.176.226 (18 Sep 2017 23:05:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Sep 2017 23:05:16 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 19 01:05:12 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1du56E-0005MT-KV for ged-emacs-devel@m.gmane.org; Tue, 19 Sep 2017 01:05:10 +0200 Original-Received: from localhost ([::1]:39271 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1du56L-00033B-UG for ged-emacs-devel@m.gmane.org; Mon, 18 Sep 2017 19:05:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1du56E-0002zf-JK for emacs-devel@gnu.org; Mon, 18 Sep 2017 19:05:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1du568-0002S0-I5 for emacs-devel@gnu.org; Mon, 18 Sep 2017 19:05:10 -0400 Original-Received: from mail-io0-x231.google.com ([2607:f8b0:4001:c06::231]:52459) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1du568-0002RS-BS for emacs-devel@gnu.org; Mon, 18 Sep 2017 19:05:04 -0400 Original-Received: by mail-io0-x231.google.com with SMTP id i197so5954152ioe.9 for ; Mon, 18 Sep 2017 16:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Zcbmi09mAmtIUMSu0zRy3EkBPzgwai3KMDSuESYP9wg=; b=j9PhWQ1VEvv8UxhN6TgRrx42Fi0QQeQGQaaR11F5COcYeauR6oGLKaE0ozdenDMWoy V6o4nv3t7AfP6o+twC+1zTg65k/A8p3W0hDf5hXcHrSpiLAdgK2rCGE9t/8b2icQ5pJJ XKVcO1Gwuc7F0NUyw2E590MvHQGCWlDRDvB01ZTJuNLgE/GWwaZilfhWsXR7QnQvpbyG fN8zCW78BkSbXDX7tjfMxsc2URzSgKVausxkWNP5cqYLcCCj4VTc7iL0Wt1IF5AVzDPP mTOdBx51Hk/0CbJGPqMcrEUwko9FAIT8WqE5l8mv4brr0MTc1+lNmYrNSoqsm4ehnRUi mlKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Zcbmi09mAmtIUMSu0zRy3EkBPzgwai3KMDSuESYP9wg=; b=YYMxVwQf+5IK/W6zzwLno8nXY2BvZlcA4lNucq0669skuLRDyKNCQmHAmyaEaM4Y78 XbvJ+zhc0zaCchILNKBUJqj3g3nzlkUHA0OYvago4mnusx+9tAIwlOklPVjdHPnIpJTx pGdlZuOmd9qyw4lt/k08+inHaBpmNjfFBixpLJPvmQaVaqTfX41NupRExDllXn037hJ6 50vbqPOh/yFeJwn+BMXyS2huUKrTjJVAGrtu6Ea4R2QTqwU2uytpy95JqhsfebEOoxSo HPLexnUQAWNscEf+z8BAqWSVAdnuH0a259l5Z71esfHv6K9gKtwjeH3Ppm2uGdLodOQv MFGg== X-Gm-Message-State: AHPjjUiH/1rZ4mOM027u0ANehjVKIiYFx89xg1QE0rioir73rQ5XGgYc FNnsz5Tjh91eKS/Hl9XjNJVPDa63TBMznYsKbfqtuw== X-Google-Smtp-Source: AOwi7QDbGv749C17bHG6+FMB+9a7u54uNUpP2klazDjh+I98aWsdu6KgtG38dxvIt1jPyNYNIiRdzbR/a6pFrzU1UWg= X-Received: by 10.202.79.206 with SMTP id d197mr1393992oib.192.1505775903453; Mon, 18 Sep 2017 16:05:03 -0700 (PDT) Original-Received: by 10.157.39.200 with HTTP; Mon, 18 Sep 2017 16:05:03 -0700 (PDT) X-Google-Sender-Auth: MXQjy4u04PaZkwx_TFZGAAJSl4c X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::231 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218498 Archived-At: --001a1145ed04d638fa05597ec5c2 Content-Type: text/plain; charset="UTF-8" On Mon, Sep 18, 2017 at 5:53 PM, Helmut Eller wrote: > The following message is a courtesy copy of an article > that has been posted to gmane.emacs.devel as well. > > On Mon, Sep 18 2017, Rocky Bernstein wrote: > > > I've been looking at Emacs Lisp code and the C source. I don't see > > how/where execution position is stored. > > I suppose you want to know how Emacs stores the source position > (filename and line number) of Lisp code Not really file name and line number. I meant it in the broadest possible way. Position could be a pointer to a structure, an offset in some bytecode, or something else. > and in particular how the > debugger can take you from a stack frame in the backtrace to the source > position. > I see that edebug munges function definitions for its own tracking. The calls to enter and leave pass the position, I think a byte offset. That's okay too, but even there I don't see something that stacks prior positions. It doesn't take much effort to do that, so I might consider doing it. > Emacs doesn't store such information in a nice uniform table -- sorry to > disappoint you -- instead Emacs has a bunch of heuristics to > guess/search the source position. One heuristic goes like this: first > determine the filename by searching the name of the function in the list > `load-history' or for subrs use the file etc/DOC. The line number is > not stored anywhere and is usually determined by some regexp search in > the source file. > > Those heuristics work quite well for "normal" code, but are too limited > if lambdas or complex macros are involved. > Right. Although it is a long ways from being usable. bytecode deparsing would handle all of the the complex cases (for bytecode) very naturally without hackery. It only needs information about where the interpreter is. > There is also no nice API for this. E.g. look at > `elisp--xref-find-definitions' for the messy code that is needed for > this kind of task. > > Ideally, the compiler/intepreter would generate source maps and attach > them to functions/lambdas in some way. But it seems that the motivation > for doing that (I guess it would be quite a big project) is limited, > given that the current heuristics work good enough for the simple cases. > Actually, the current approach works suprisingly well, considering how > little information is kept around. > And I think with just a little more information, position information, I think the situation would be much better. > > Helmut > --001a1145ed04d638fa05597ec5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 18, 2017 at 5:53 PM, He= lmut Eller <eller.helmut@gmail.com> wrote:
The following message is a courtesy copy of an articl= e
that has been posted to gmane.emacs.devel as well.

On Mon, Sep 18 2017, Rocky Bernstein wrote:

> I've been looking at Emacs Lisp code and the C source. I don't= see
> how/where execution position is stored.

I suppose you want to know how Emacs stores the source position
(filename and line number) of Lisp code

No= t really file name and line number. I meant it in the broadest possible way= .=C2=A0
Position could be a pointer to a structure, an offset in = some bytecode, or something else.

=C2=A0
and in particular how the
debugger can take you from a stack frame in the backtrace to the source
position.

=C2=A0I see that edebug munge= s function definitions for its own tracking. The calls
to enter a= nd leave pass the position, I think a byte offset.=C2=A0

That's okay too, but even there I don't see something that s= tacks prior
positions. It doesn't take much effort to do that= , so I might consider doing it.



Emacs doesn't store such information in a nice uniform table -- sorry t= o
disappoint you -- instead Emacs has a bunch of heuristics to
guess/search the source position.=C2=A0 One heuristic goes like this: first=
determine the filename by searching the name of the function in the list `load-history' or for subrs use the file etc/DOC.=C2=A0 The line number= is
not stored anywhere and is usually determined by some regexp search in
the source file.

Those heuristics work quite well for "normal" code, but are too l= imited
if lambdas or complex macros are involved.

<= div>Right. Although it is a long ways from being usable. bytecode deparsing= would
handle all of the the complex cases (for bytecode) very na= turally without hackery.
It only needs information about where th= e interpreter is.


There is also no nice API for this.=C2=A0 E.g. look at
`elisp--xref-find-definitions' for the messy code that is needed for this kind of task.

Ideally, the compiler/intepreter would generate source maps and attach
them to functions/lambdas in some way.=C2=A0 But it seems that the motivati= on
for doing that (I guess it would be quite a big project) is limited,
given that the current heuristics work good enough for the simple cases. Actually, the current approach works suprisingly well, considering how
little information is kept around.

And = I think with just a little more information, position information, I think = the situation would be=C2=A0
much better.=C2=A0

=C2=A0

Helmut


--001a1145ed04d638fa05597ec5c2--