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

Previous Next

Full log

Message #20 received at 67141 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 67141 <at> debbugs.gnu.org
Subject: Re: bug#67141: 30.0.50; Missing element in the backtrace
Date: Fri, 17 Nov 2023 15:48:28 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> mmmh, my crystal ball suggests that some (native compiled) code is
>>> calling directly a primitive (eval) without going through funcall, as a
>>> consequence no backtrace is recorded.  AFAIR that's what happen with
>>> byte compiled code with primitves with assigned (byte)op-code as well.
>>
>> PS and indeed similarly what happen calling a primitive from other C
>> code.
>
> But C code can choose whether it calls `F<foo>` directly or goes through
> `Ffuncall`, whereas for ELisp code there is no such control.

Yes, still already with bytecode only in some case in Elisp code it goes
through funcall and in some it doesn't.

> It impacts debugging and profiling, in my experience.

I see, the outcome for me is that we should offer a way for the user to
force the use of funcall.  Unfortunatelly ATM if one writes like
(funcall 'eval ...) it gets optimized.  Maybe even a funcall wrapper
written in Elisp would be sufficient?

  Andrea

Previous Next

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