Re: MPS: native comp

[Andrea Corallo <acorallo@gnu.org>]

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

> Andrea Corallo <acorallo@gnu.org> writes:
>
>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>>>
>>>> That promises to become fun :-/
>>>
>>> Sometimes one needs a bit of luck. Another try landed me in an abort in
>>> set_internal, and I could see that we have another case of a symbol
>>> pointing to a tombstone. So, we have another reference in the
>>> compilation unit that we don't trace.
>>
>> Maybe you can make it more reproducible building at -J1?
>
> I meanwhile suspect it's ASLR. When I run things under LLDB, ASLR is off
> (LLDB does that). When I gmake (with -j1), ASLR on.

Yep that makes sense

>>> @Andrea: Any intuition where else references could lurk, perhaps? I'm
>>> currently doing this:
>>>
>>> static mps_res_t
>>> fix_comp_unit (mps_ss_t ss, struct Lisp_Native_Comp_Unit *u)
>>> {
>>>   MPS_SCAN_BEGIN (ss)
>>>   {
>>>     IGC_FIX_CALL_FN (ss, struct Lisp_Vector, u, fix_vectorlike);
>>>     if (u->data_imp_relocs)
>>>       {
>>> 	size_t n = ASIZE (u->data_impure_vec);
>>> 	IGC_FIX12_NOBJS (ss, u->data_imp_relocs, n);
>>>       }
>>>     if (u->data_relocs)
>>>       {
>>> 	size_t n = ASIZE (u->data_vec);
>>> 	IGC_FIX12_NOBJS (ss, u->data_relocs, n);
>>>       }
>>>   }
>>>   MPS_SCAN_END (ss);
>>>   return MPS_RES_OK;
>>> }
>>>
>>> Maybe there's something wrong with that (the ASIZEs maybe?)
>>
>> I think the size should be fine,
>
> Thanks.
>
>> it would be very interesting to know which one is the symbol that was
>> actually killed by the GC. This would give us strong indications.
>> Maybe we can use the watchpoint strategy to identify it?
>
> It's the symbol that leads to the setting-constant error in the eager
> macro expansion error. You can see that in the debug org file I attached
> to another mail.
>
>       data = 0x000000010f0eb008 "byte-compile-form-stack"
>
> The problem is apparently similar to what we had before: The symbol has
> been moved in memory (not freed), and a reference to the symbol was not
> updated because we don't trace it. So a watchpoint won't help - the
> problem is that nothing changes :-).

If the object was moved and the d_reloc is now updated by MPS I've a
doubt:

What if our object (say d_reloc[x]) is loaded in a register by the
compiler?  How does the register gets updated by MPS?  In native code we
do this all the time for performance reasons.

> Next strategy or tactic, I think, could be to produce a C file for
> macroexp.eln, and see where the symbol appears. I would imagine that I
> can deduce from the text representaton of the constants in C what index
> correspondons to the symbol, and then see if it is used in surprising
> ways. Maybe. WDYT?

You'll probably see what I mentioned above.  At the beginning of the
compiled function we load in regular variables the lisp objects from
d_reloc so GCC leverage the register allocater and keep in registers.

For instance we do exactly this 'byte-compile-form-stack' and others
here:

macroexp-1776619e-76691d27.c ======================
extern struct Lisp_X *
F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_0 (long long nargs, struct Lisp_X * * args)
{
  struct freloc_link_table * freloc;
  struct Lisp_X * slot_0;
  struct Lisp_X * slot_1;
  struct Lisp_X * slot_2;
  struct Lisp_X * slot_3;
  struct Lisp_X * slot_4;
  struct Lisp_X * slot_5;
  struct Lisp_X * slot_6;
  struct comp_handler * c;

entry:
  freloc = freloc_link_table;
  /* Lisp function: nil */
  slot_0 = *args;
  /* ptr_arithmetic */
  args = (struct Lisp_X * *)bitcast((unsigned long long)((unsigned long long)bitcast((void *)args, unsigned long long) + (unsigned long long)8 * (unsigned long long)(long long)1)\
, void *);
  goto entry_rest_args;

entry_rest_args:
  /* calling subr: list */
  slot_1 = freloc->R6c697374_list_0 ((nargs - (long long)1), args);
  goto bb_0;

bb_0:
  /* let */
  slot_2 = d_reloc[(long long)0];
  /* byte-compile-form-stack */
  slot_3 = d_reloc[(long long)1];
  /* cons */
  slot_4 = d_reloc[(long long)2];

[...]
======================

Where we load it in 'slot_3'.

I think the easiest is to to make objects loaded from native code non
movable.  Is this possible with MPS? What would be the downside of this?
They are very rarely collected anyway.  WDYT?

Thanks

  Andrea