bug#68690: Segmentation fault building with native-comp

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier
>>  <monnier@iro.umontreal.ca>,  jm@pub.pink,  68690@debbugs.gnu.org
>> Date: Fri, 26 Jan 2024 10:26:00 +0100
>> 
>> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
>> text editors" <bug-gnu-emacs@gnu.org> writes:
>> 
>> > I'm just as lost as you are in pdumper.c, sadly.
>> 
>> I remembered seeing something in pdumper.c that could be related, namely
>> 
>>   /* Start the cold section.  This section contains bytes that should
>>      never change and so can be direct-mapped from the dump without
>>      special processing.  */
>>   dump_drain_cold_data (ctx);
>> 
>> And if you follow that function you'll see that it treats charsets
>> specially.
>
> AFAIU, that special handling is for dumping fields that are pointers.
> For example, the string data in a Lisp string, buffer text in a
> buffer, and the data pointed to by code_space_mask in a charset.
>
> But the charset's attributes are not a pointer, they are a Lisp
> vector.
>

We're probably talking about different things. I was talking about the
fact that struct charset, before Stefan's change, sonsisted of,
basically, integers only (no pointer, nothing), so that it could just be
dumped as-is, and, after loading the dump file, used as-is.

> Moreover, the offending charset (ID = 0) is not processed by
> dump_cold_charset because its code_space_mask is NULL (which makes
> sense since the dimension of the ASCII charset is 1).
>
>> I find the comment about directly mapping very suspicious, when the
>> charset contains a Lisp_Object, possibly requiring relocation. But it
>> could well be that I misundertand something here.
>
> First, before Stefan's changes there was no Lisp objects in 'struct
> charset'.

My point.

> And second, what do you mean by "possibly requiring relocation"?  Do
> you mean relocation after restoring from dump, or do you mean
> relocation during dumping?  Or something else entirely?

Lisp_Object fields require writing something to the dump file that can
be used, when the dump is loaded, to compute the real value in the the
new Emacs session. So, something is done when dumping, and when loading.