bug#64613: Signalling byte ops should show up in backtraces

bug#64613: Signalling byte ops should show up in backtraces

[Mattias Engdegård]

Many byte ops don't appear in the backtrace if they signal an error. This makes it unnecessarily difficult to find the precise location of the error.

Most operations that replace a function call, such as `cdr`, `+`, `memq` and so on, have this problem.

The tricky part is to include the function in the backtrace without slowing down normal execution.

bug#64613: Signalling byte ops should show up in backtraces

[Mattias Engdegård]

A small improvement, only covering car, cdr, setcar, sector, and (partially) nth and elt, was pushed in 8acd52bba4.
This is low-hanging fruit and worth doing for the benefit it brings even if we end up using a more general solution later on.

bug#64613: Signalling byte ops should show up in backtraces

[Mattias Engdegård]

Now (82f5f3b8a2) the `aref` and `aset` byte-ops provide backtrace records for errors that are discovered in the fast path:

- index argument not a fixnum
- for vector and record arguments, index out of range

For other types there is no such help yet since we call out to Faref and Faset.

We need a general strategy for dealing with such call-outs from the bytecode engine. So far, the backtrace records have all been to cold paths with no new hot-path code.