GNU bug report logs - #67141
30.0.50; Missing element in the backtrace

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67141 <at> debbugs.gnu.org
Subject: bug#67141: 30.0.50; Missing element in the backtrace
Date: Mon, 20 Nov 2023 12:52:27 -0500

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.