[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GSoC project - Improving ELisp Traceback and Debugging Information

From: Zach Shaftel
Subject: GSoC project - Improving ELisp Traceback and Debugging Information
Date: Wed, 03 Jun 2020 17:42:27 -0400
User-agent: mu4e 1.4.8; emacs 28.0.50

Hello all,

This summer I will be working on improving ELisp traceback information for Google Summer of Code.

My ultimate goal is to record the source location of calls so that this can be used by the backtrace, eg. buttons which jump to the exact function call which produces the error. The minimum goal however is to have the offset recorded while maintaining acceptable performance, and allow the backtrace to jump to the point in the disassembly where the error occurs.

So far I've modified the byte-code interpreter to simply store the offset of each funcall in the backtrace specbinding frame, and modified backtrace.el so the sequence of offsets is printed alongside each respective call in the backtrace. It's available on the feature/soc-bytecode-in-traceback-specbinding branch on Savannah. Here's what the backtrace output looks like:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
   10 test-debugger()
6 call-test-debugger((110 117 109 98 101 114 115 0 1 2 3 4 5))
    9 call-call-test-debugger()
      load("/home/zach/ELisp/bad-stuff.elc" nil t)
  513 command-line-1(("-l" "bad-stuff.elc"))
 1482 command-line()
  417 normal-top-level()

The current implementation entails a performance regression (based on elisp-benchmarks.el on my machine, a ~10% slowdown), so it's not viable in the current state, but there's plenty of ways to improve on that. Any ideas would be appreciated.

I've been looking at the scratch/accurate-warning-pos branch as well as prior discussions and am still evaluating different approaches to solving the task. It might be necessary to modify the way code is represented during compilation, be it simply with the annotated symbols as in that branch or with another more generalized form of object representation. The latter approach would be more versatile, but doing so while still preventing the compiler from hogging memory would be tough, and is broad enough that it's probably outside the scope of this project.

I'd love to hear others' thoughts, advice, and comments on the project, and on what sorts of changes would be most desired for inclusion in Emacs.

Zach Shaftel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]