Re: MPS: Please check if scratch/igc builds with native compilation

[Gerd Möllmann]

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

> Helmut Eller <eller.helmut@gmail.com> writes:
>
>> On Thu, May 23 2024, Gerd Möllmann wrote:
>>
>>> Thanks, but it didn't help, I'm afraid.
>>
>> There's some checking code in comp.c.  Maybe you could add  this
>>
>>   void
>>   check_all_comp_units (void)
>>   {
>>     igc_collect ();
>>     struct Lisp_Hash_Table *h = XHASH_TABLE (Vcomp_loaded_comp_units_h);
>>     DOHASH (h, k, cu)
>>       {
>>         eassert (NATIVE_COMP_UNITP (cu));
>>         fprintf (stderr, "key: %s\n", SSDATA (k));
>>         check_comp_unit_relocs (XNATIVE_COMP_UNIT (cu));
>>       }
>>   }
>>   
>> and call it from the debugger.  If this check passes then I think the
>> relocs are in pretty good shape.
>
> Thanks for helping me!
>
> Since I'm not sure if relocs are the culprit this time around, I'll also
> add the roots for a dylib very early, so that there is no "reasonable"
> doubt they exist. I'll use this fact:
>
>   .../igc/native-lisp/30_0_50-5cce80dd % nm -g -s __DATA __common 
> radix-tree-669a468d-316fbcdc.eln   
>   00000000000050e0 S _comp_unit
>   00000000000050e8 S _current_thread_reloc
>   00000000000050f0 S _d_reloc
>   0000000000005220 S _d_reloc_eph
>   00000000000053d8 S _d_reloc_imp
>   0000000000005438 S _f_symbols_with_pos_enabled_reloc
>   0000000000005440 S _freloc_link_table
>   0000000000005448 S _pure_reloc
>
> IOW, I can compute the sizes of the reloc arrays from symbol addresses.
> (On macOS, the format is Mach-O, the segment/section names are probably
> different in ELF).
>
> Let's see. But I need to collect enough energy for doing this first ;-).

Given the choice of either ironing or trying what I described above, I
evaded ironing. Diff at the end. Effect none. Which lets me update my
beliefs so that relocs are unlikely to be the cause this time.

staged.diff
Description: roots