Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: Paul Eggert , Eli Zaretskii >> Date: Sun, 17 May 2020 12:42:48 +0000 >> >> What is going on is that in a .eln in a function A a Lisp_Object is >> hold in a register (r14). Function A is calling other functions into >> emacs-core till Garbage Collection is triggered. >> >> Being emacs-core compiled with -O0 GCC is not selecting any callee safe >> register and therefore these gets never pushed. > > Isn't this something for the infrastructure of calling > natively-compiled Lisp to solve? The Emacs C code isn't prepared for > calling optimized C code when it calls Lisp, and I don't think it's > right for us to assume that, because it will make Emacs slower. If > the natively-compiled Lisp needs some setup to be compatible with GC, > I think the calling framework should set that up. Hi Eli, I think this is a real bug that we have in the codebase (emacs-27 included). Usually it works because having many big functions with high register pressure that gets activated before reaching 'flush_stack_call_func' statistically callee saved regs are very likely to be pushed. But nothing prevents a caller of 'flush_stack_call_func' to store a lisp object into a callee saved regs and trigger the bug. This obviously depends on the compiler, flags used etc, things we have no control over. This could be also an explanation of instability for LTO configurations. Given that callers of 'flush_stack_call_func' are more likely to be inlined the exposed surface becomes considerably higher. This bug should be also more likely to be observable if C files are compiled with a mix of -O0 and -O2. I think we should honor calling convention and make sure we garbage collect also the content of callee saved registers, BTW I guess that's the reason why we call '__builtin_unwind_init' isn't? If we are concerned about performance the attached the attached patch should be zero performance overhead. Regards Andrea -- akrl@sdf.org