bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: pipcet@gmail.com, 46256@debbugs.gnu.org, andrewjmoreton@gmail.com
>> Date: Tue, 09 Mar 2021 15:38:54 +0000
>> 
>> > I've now built the latest branch.  It still crashes, in the same
>> > place, although with different Lisp files.  I'm looking into this,
>> > will post the details.
>> 
>> Thinking about, you might have stale eln files reachable in the
>> `comp-eln-load-path' generated with the bug fixed by 380ba045c4.
>
> Maybe.  What I see is that we load a CU in Fnative_elisp_load followed
> by load_comp_unit, for the first time, and create a Lisp CU object for
> it:
>
>   Lisp_Object comp_u_lisp_obj;
>   XSETNATIVE_COMP_UNIT (comp_u_lisp_obj, comp_u);
>
> Then we store it in the shared library:
>
>   if (comp_u->loaded_once)
>     ...
>   else
>     *saved_cu = comp_u_lisp_obj;
>
> But then we clobber the value of comp_u_lisp_obj here:
>
>         data_ephemeral_vec =
>           load_static_obj (comp_u, TEXT_DATA_RELOC_EPHEMERAL_SYM);
>
>         EMACS_INT d_vec_len = XFIXNUM (Flength (data_ephemeral_vec));
>         for (EMACS_INT i = 0; i < d_vec_len; i++)
>           data_eph_relocs[i] = AREF (data_ephemeral_vec, i);  <<<<<<<<<<<
>
> Is this likely to be due to that problem?

Interesting, how can we clobber the value of 'comp_u_lisp_obj' that is
stack allocated while writing into 'data_eph_relocs[i]' that is static
allocated in an eln?

If we clobber 'comp_u_lisp_obj' this is certanly a problem as we have to
pass it to 'top_level_run' later on.

Thanks

  Andrea