Hi -
There is a possibility of a Google funding a Summer of Code project to add bytecode offsets on bytecode errors and also perhaps in tracebacks.
However since this would be considerable effort on the Summer of Code student and me, I don't want to undertake this if it is not there is concern.
As a small first step to give people a feeling of how this might start out, I've created a branch in emacs:
feature/soc-bytecode-in-traceback to explore what things might look like.
If you build that code and emacs when the bytecode hits an error in running `cdr` because it is given a non-cons argument you'll see the offset shown as last (3rd) argment in the debugger argument.
For example:
Byte-compile this buggy function in /tmp/foo.el
with (byte-compile-file):
(defun foo()
(setq x 5)
(cdr 'b) ;; Invalid cdr argument: 'b
)
Then run :
(load-file "/tmp/foo.elc")
(foo)
and you should see:
Debugger entered--Lisp error: (wrong-type-argument listp b 3)
this is the offset ^
foo()
eval((foo) nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
Compare against disassembly:
byte code for foo:
args: nil
0 constant 5
1 varset x
2 constant b
3 cdr
^^^ offset from above
4 return
You can try with other offsets such as by removing the (setq x 5) and you'll see offset 1 instead.
Right now, we just pass to signal the bytecode offset. More elaborate would be
to pass the code object and its offset.
And even more elaborate schemes could be imagined.
If there is trepidation or concerns about this, let me know.