all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.