all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* (How) can I get position information backtraces?
@ 2017-09-18 23:05 Rocky Bernstein
  0 siblings, 0 replies; only message in thread
From: Rocky Bernstein @ 2017-09-18 23:05 UTC (permalink / raw)
  To: emacs-devel

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

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2017-09-18 23:05 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-09-18 23:05 (How) can I get position information backtraces? Rocky Bernstein

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.