bug#67141: 30.0.50; Missing element in the backtrace

[Stefan Monnier]

> If you want then I think we should consider this bug not only native
> comp related, as I explained we have this issue since long time in
> other circumstances.

I think it's qualitatively different, but yes, this is not the only
occurrence of the problem.  AFAICT, we have 3 different cases:

A. Native compiled code making a "direct call" to a C primitive.
B. ELisp primitives with their own bytecode.
C. C code calling `Ffoo` instead of `Ffuncall (Qfoo, ...)`.

(B) and (C) have been with us for ever.  They also suffer from being
unaffected by advice.  (A) on the other hand is new, but obeys advice.

I think (C) is qualitatively very different from (A) because
(C) can be fixed by hand whenever we decide that it's a problem,
i.e. whenever we decide that the fact that the code calls exactly
`foo` (as opposed to some other code with similar behavior) shouldn't
be seen as an internal implementation detail.

Similarly B is qualitatively different from (A) because (B) applies only
to a small set of primitives.

(B) is more annoying than (C), admittedly, since it occurs fairly often
in a backtrace that we'd like to have a better idea of where we are
inside a byte-compiled function.  I'd welcome improvement in this area
(maybe by looking at the (bytecode)PC, then disassembling the bytecode
at that position to find the primitive that we're executing).


        Stefan