Re: MPS codegen

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  acorallo@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 16 Jun 2024 08:16:38 +0200
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> >   pdumper.c:4937: Emacs fatal error: assertion failed: rc == 0
> >   gmake[3]: *** [Makefile:335: emacs-lisp/byte-opt.elc] Abort trap: 6
> >   gmake[3]: *** Waiting for unfinished jobs....
> >
> > which is soothing.
> >
> > I'm reluctant to invest more time though because this all si obsolete
> > with your change.
> 
> Just had an inspiration what it might be, and it is indeed the case:
> 
> Forwarded symbols are created like this
> 
>   #define DEFVAR_LISP_NOPRO(lname, vname, doc)        \
>     do {                                              \
>       static struct Lisp_Objfwd const o_fwd   \
>         = {Lisp_Fwd_Obj, &globals.f_##vname}; \
>       defvar_lisp_nopro (&o_fwd, lname);              \
>     } while (false)
> 
> The pdumper copies these static structs to the dump, and when the dump
> is loaded, the symbol's forwarding pointer is changed from pointing to
> the static struct to the copy to the dump. Both have the same contents.
> 
> IOW, the static structs are no longer used. Consequenlty, when accessing
> the structs to get their type (XFWDTYPE) we are accessing something in
> the dump.
> 
> Why pdumper is doing that escapes me ATM.

Because the values recorded during dumping could be different from the
default values, and so using the static struct might be wrong?