Does recent great work on separating the bytecode stack make it easier to show bytecode offsets in a traceback?

Does recent great work on separating the bytecode stack make it easier to show bytecode offsets in a traceback?

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

I recently compiled GNU Emacs master (29.0.50ish) and saw the great work
done to separate the bytecode stack. In this thread
https://lists.gnu.org/archive/html/emacs-devel/2022-03/msg00330.html I see
a lot of concerns, but no thanks.

So thanks Mattias Engdegård!

I especially like and appreciate the comment in the C code in bytecode.c
showing the Bytecode interpreter stack.

Now that we have a more normal bytecode stack, we have "saved_pc"
shouldn't it be possible to easily show the bytecode offset in
lisp/emacs-lisp/backtrack.el ?

Prior work on this can be found in
https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00711.html

Thanks again.

[-- Attachment #2: Type: text/html, Size: 1466 bytes --]

Re: Does recent great work on separating the bytecode stack make it easier to show bytecode offsets in a traceback?

[Mattias Engdegård]

30 apr. 2022 kl. 18.25 skrev Rocky Bernstein <rocky@gnu.org>:

> I especially like and appreciate the comment in the C code in bytecode.c showing the Bytecode interpreter stack.

Many thanks for your kind words. Mustn't let an opportunity for making ASCII art go to waste!

> Now that we have a more normal bytecode stack, we have "saved_pc"  shouldn't it be possible to easily show the bytecode offset in lisp/emacs-lisp/backtrack.el ? 

That information is indeed accessible now, at least in principle; the stack format was designed with backtracing in mind. How to make effective use of it is another matter. A bytecode offset to source location mapping is perhaps more feasible now (with position-carrying symbols) but still a fair amount of work.

There are also questions about whether to carry around such a mapping all the time (memory cost etc). I like the idea of rematerialising it when needed but Elisp isn't easily conducive to that approach.

On the other hand, just exposing the bytecode offset in tracebacks could very well be useful on its own for users who can read disassembled bytecode.

Regarding the stack trace information, there is some redundancy that could be exploited: the backtrace recorded in the specpdl could probably be eliminated for calls into bytecode (and with some gymnastics, for other calls as well). Experiments have indicated that there are performance gains to be had here.

> Prior work on this can be found in https://lists.gnu.org/archive/html/emacs-devel/2020-07/msg00711.html

Thank you, this provides some interesting perspective. Some things have changed since but the big problems remain more or less the same.