Re: MPS: native comp

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

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.

>> @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 :-).

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?