Subject: bug#75599: 31.0.50; scratch/igc: crash on commit 92ccf1c after opening file and REPL

From: Pip Cet <[email-masked]>
Date: Sat, 18 Jan 2025 14:39:42 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Date: Sat, 18 Jan 2025 11:47:27 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: [email-masked], [email-masked]
>>
>> "Eli Zaretskii" <[email-masked]> writes:
>>
>> > I seldom use 'find', and core dumps even more seldom, but shouldn't
>> > GDB be able to search memory of the debuggee regardless of whether it
>> > came from the core file or from a live process?  Or am I
>> > misunderstanding the question?
>>
>> I don't know how to search "all" process memory with GDB.  That's the
>> problem.
>
> Is the problem to know what are the START_ADDR and END_ADDR arguments
> to the 'find' command?

Yes.

> If so, do the variables set by firstfile.c and lastfile.c help?

No, not at all.  This is about MPS-managed memory, not the static Emacs
data.

About firstfile.o and lastfile.o:

If you think firstfile.c and lastfile.c are still useful, please speak
up so we can revert their removal on scratch/no-purespace!

I ended up restoring them on my local tree because I like section
tricks, and those need to know where the sections are; but my
understanding is introducing section tricks to Emacs would be a major
change, and reintroducing those two files would be such a tiny part of
that change that we can safely delay it.

For context, one example of section tricks would be to put some static
Lisp data, including the globals, in a special section which is then
scanned by the GC; that would help performance in some ways (make
staticpro a nop, reduce usage of staticvec, protect all variables).

CCing Stefan Kangas because he pushed the firstfile/lastfile removal.

Pip