From: Rocky Bernstein <rocky@gnu.org>
To: emacs-devel@gnu.org
Subject: (How) can I get position information backtraces?
Date: Mon, 18 Sep 2017 19:05:03 -0400 [thread overview]
Message-ID: <CANCp2gait03Q2_sCrHGAG+ASrh+F9ZK3Phn9HHyfSie1BsoLRA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]
On Mon, Sep 18, 2017 at 5:53 PM, Helmut Eller <eller.helmut@gmail.com>
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
>
[-- Attachment #2: Type: text/html, Size: 3876 bytes --]
reply other threads:[~2017-09-18 23:05 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CANCp2gait03Q2_sCrHGAG+ASrh+F9ZK3Phn9HHyfSie1BsoLRA@mail.gmail.com \
--to=rocky@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.