Re: STatus of MPS branch

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> I changed some things and now I can no longer reproduce the exact same
> problem.  But it looked to me like a perfectly normal string with
> intervals=0x0.  Strangely, accessing the intervals field from GDB didn't
> cause any SIGSEGV.
>
> However, after setting breakpoints in handle_sigsegv and sigHandle (from
> MPS) I discovered that sigHandle wasn't called.  So my hypothesis is
> that the signal handler isn't initialized properly.  In particular, it
> seems problematic that ProtSetup (from MPS) is called before
> init_signals.
>
> Then I moved the call to init_signals in emacs.c up before the call to
> init_igc and voilà: the build completed.  With an apparently working
> (tty-only) Emacs.

Oh, I have an idea! Hopefully I can explain it. Let me try...

MPS is a copying GC, and it uses read-barriers for object forwarding.

Let's say O is an object managed by MPS, and it decides during GC that O
shall be moved in memory to the new location N. This is done by copying
O to N, storing at O the information that it has moved to N, and putting
a read-barrier on O.

The last step means that any access to O by the client (Emacs) leads to
MPS being involved, which updates the reference to O to a reference to
N.

Plus...

MacOS has a kernel that is, let's not get into details, a conglomerate
of Mach and FreeBSD kernel. This means MPS can use Mach mechanisms for
implementing read/write barriers, and I know it does because I landed in
that code in LLDB at some point.

Linux is not Mach, so MPS must use VM protection and signals.

And finally, the idea now would be that MPS's signal handling (probably
SIGSEGV and SIGBUS) and Emacs' signal handling interfere with one
another.

For example, MPS has done its thing and read-protected O from above.
Emacs accesses O, a SEGV is signaled, Emacs gets the signal and thinks
it's bit the dust. And so on.

Or, IOW, we need some Emacs signal handling support personal.

Does that make sense?