Re: MPS codegen

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

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.