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.