[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS codegen
From: |
Gerd Möllmann |
Subject: |
Re: MPS codegen |
Date: |
Sun, 16 Jun 2024 08:16:38 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: MPS codegen, (continued)
- Re: MPS codegen, Eli Zaretskii, 2024/06/15
- Re: MPS codegen, Gerd Möllmann, 2024/06/15
- Re: MPS codegen, Eli Zaretskii, 2024/06/15
- Re: MPS codegen, Gerd Möllmann, 2024/06/15
- Re: MPS codegen, Gerd Möllmann, 2024/06/15
- Re: MPS codegen, Helmut Eller, 2024/06/15
- Re: MPS codegen, Gerd Möllmann, 2024/06/15
- Re: MPS codegen, Helmut Eller, 2024/06/15
- Re: MPS codegen, Gerd Möllmann, 2024/06/15
- Re: MPS codegen, Gerd Möllmann, 2024/06/15
- Re: MPS codegen,
Gerd Möllmann <=
- Re: MPS codegen, Eli Zaretskii, 2024/06/16
- Re: MPS codegen, Gerd Möllmann, 2024/06/16
- Re: MPS codegen, Helmut Eller, 2024/06/16
- Re: MPS codegen, Gerd Möllmann, 2024/06/16