bug#47067: 28.0.50; [feature/native-comp] Crash while scrolling through dispnew.c

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: 47067@debbugs.gnu.org
>> Date: Sun, 04 Apr 2021 20:52:51 +0000
>> 
>> > Ah, I see now.  The list of the files that could be preloaded is in
>> > $shortlisp, see src/Makefile.in.  The file names are read from
>> > src/lisp.mk.
>> 
>> Here I'm, 6f8ec14491 should introduce the behaviour we wanted, preloaded
>> files are now deposed in the 'preloaded' subfolder.
>> 
>> Also, 1ad0ecea2b reinstablish the fact that at each re-compilation we
>> clean-up stale eln files in all the directories in `comp-eln-load-path',
>> indeed this is excluding the introduced 'preloaded' subfolder.
>
> Thanks.  Things seem to work quite well, AFAICS, but there's a subtle
> problem (or maybe 2):
>
>  . First, the problem with corrupted backtraces is back, although I
>    verified that comp-debug is 1.  Strangely, it happens only for some
>    *.eln files; others show full backtraces as expected.  The telltale
>    sign of a "problematic" .eln file is that even when functions are
>    shown in the backtrace with their fill names, the arguments of
>    function calls aren't shown, something that shouldn't happen when
>    there's debug info.
>
>  . If I manually recompile a preloaded .el file, like this:
>
>      emacs -batch -l comp -f batch-byte-native-compile-for-bootstrap 
> ../lisp/isearch.el
>
>    then the produced .eln file is written not into the preloaded
>    folder, but into its parent, i.e. native-lisp/28.0.50-NNNNNN/.
>
> And here is the possible link between these two issues: if I start
> Emacs after compiling preloaded files manually as above, then Emacs
> seems to load the *.eln files from native-lisp/28.0.50-NNNNNN/, not
> from native-lisp/28.0.50-NNNNNN/preloaded, and the problems with the
> backtraces miraculously disappear!
>
> Any idea what is going on here?

I think I understand the second issue (at least):

ATM which file is preloaded and which is not is suggested by the build
system to Emacs (using the LISP_PRELOADED env var) so that Emacs decides
where to depose the eln.  Unfortunately when the build system is by
passed with a manual invocation Emacs is unaware of this information and
not targeting the preloaded sub-directory.

Not sure what's the best strategy to improve this.

Thanks

  Andrea