Re: Native compilation on MPS branch

[Andrea Corallo]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Keep us updated, I hope I can find some time to dedicate to the MPS
>> effor the upcoming week.
>
> Hi Andrea!
>
> I'm currently on a different problem that's the first one occurring when
> I don't do a build from scratch, but try to pdump with an existing eln.
>
>    Loading emacs-lisp/macroexp (native compiled elisp)...
>    Loading /Users/gerd/emacs/github/igc/lisp/cus-face.el (source)...
>    Loading /Users/gerd/emacs/github/igc/lisp/faces.el (source)...
>    Loading /Users/gerd/emacs/github/igc/lisp/ldefs-boot.el (source)...
>    Loading /Users/gerd/emacs/github/igc/lisp/button.el (source)...
>    Loading /Users/gerd/emacs/github/igc/lisp/emacs-lisp/cl-preloaded.el 
> (source)...
>
>    ./character.h:381: Emacs fatal error: assertion failed: 0xC0 <= c
>    Fatal error 6: Aborted
>
> That's in string_char_and_len, and the reason is that the string is
> apparently kaputt. The actual problem seems to appear much earlier and
> 2km away. A symbol is created with name
>
> (struct Lisp_String) {
>   u = {
>     s = {
>       size = 19
>       size_byte = 19
>       intervals = NULL
>       data = 0x000000017961c6b0 "macroexp--backtrace"
>     }
>     next = 0x0000000000000013
>     gcaligned = '\x13'
>   }
> }
>
> And that name/string isn't seen by MPS. Which should mean the symbol
> isn't seen, which should mean it's stored somewhere where I don't look.
>
> Since macroexp is dumped native-compiled, I thought I'd rather ask the
> expert, where that might be, than digging around in pdumper, or where
> else.

Hi Gerd!

I'm not sure the pdumper plays a role here, IIUC the string is the name
of a native compiled function that was recently loaded.

AFAIR the names of functions being registered are keep in
'data_ephemeral_vec' referenced inside 'load_comp_unit'.  The comment in
comp.c says:

   /* Note: data_ephemeral_vec is not GC protected except than by
      this function frame.  After this functions will be
      deactivated GC will be free to collect it, but it MUST
      survive till 'top_level_run' has finished his job.  We store
      into the ephemeral allocation class only objects that we know
      are necessary exclusively during the first load.  Once these
      are collected we don't have to maintain them in the heap
      forever.  */

Is MPS scanning the stack for Lisp like objects like our current GC?

Also other immediate objects kept in the eln are reachable by the GC
through the compilation unit object (see Lisp_Native_Comp_Unit).

I guess this string belongs to one of the two cases.

Hope it helps

  Andrea