ocaml/ocaml — pull request #28 by gasche (2014-04-08 13:23:35+00:00)
Title: PR#5899: user-friendly representation of backtraces

Joint work with Jacques-Henri Jourdan, this is the latest patchset to improve backtrace collection and inspection. A previous version of this patch was submitted by Jacques-Henri on mantis ([PR#5899](http://caml.inria.fr/mantis/view.php?id=5899)); the new version has a few change suggestions, and we use the fancy github PR process in the hope of getting more eyeballs on the patch.

Main changes:

> - `raw_backtrace` is no longer an abstract type, but rather an
> `raw_backtrace_slot array`, where `raw_backtrace_slot` is a new
> abstract type. `raw_backtrace_slot` elements are hashable and
> comparable. At runtime, values of this type contain either
> a bytecode pointer or a frame_descr pointer. In order to prevent the
> GC from walking through this pointer, the low-order bit is set to
> 1 when stored in the array.
>
> - The old `loc_info` type is know public, renamed into `backtrace_slot`:
>
> type backtrace_slot =
> | Known_location of bool (* is_raise *)
> * string (* filename *)
> * int (* line number *)
> * int (* start char *)
> * int (* end char *)
> | Unknown_location of bool (*is_raise*)
>
> - new primitive :
>
> val convert_raw_backtrace_slot: raw_backtrace_slot -> backtrace_slot
>
> Rather than returning an option, it raises Failure when it is not
> possible to get the debugging information. It seems more idiomatic,
> especially because the exceptional case cannot appear only for a part
> of the executable.
>
> - the caml_convert_raw_backtrace primitive is removed; it is more
> difficult to implement in the C side because of the new exception
> interface described above.
>
> - In the bytecode runtime, the events are no longer deserialized once
> for each conversion, but once and for all at the first conversion,
> and stored in a global array (*outside* the OCaml heap), sorted by
> program counter value. I believe this information should not take
> much memory in practice (it uses the same order of magnitude memory
> as the bytecode executable). It also makes location lookup much more
> efficient, as a dichomoty is used instead of linear search as
> previously.