GSoC project - Improving ELisp Traceback and Debugging Information

[Zach Shaftel <zshaftel@gmail.com>]

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.

Thanks,
Zach Shaftel