Re: Building the igc branch on MS-Windows

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> I've meanwhile pushed something that handles the use of PVEC_OTHER in
>> modules. Nothing done for the scroll_bar struct in w32. Caution: I
>> remved the assert.
>
> Why did you do that?  What possible useful purpose can that serve?  If
> the assertion gets in the way of what you are looking at, you can
> always remove it locally, can't you?

Because PVEC_OTHER is handled fine now, except whatever w32 does in
addition or maybe instead (has it modules?)

>> >> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
>> >> There is igc_postmorten which can be called from the debugger. That at
>> >> least lifts the memory barriers.
>> >> 
>> >> Does that make sense?
>> >
>> > Yes, it does.  Maybe xbacktrace should do that automatically?  What
>> > are the downsides of calling igc_postmorten?
>> 
>> I'd say that xpostmortem wouldn't make sense during normal debugging,
>> when MPS is not dead in the water. I don't think one can get out of that
>> state again.
>
> I don't follow.  How is debugging problems with GC different from
> "normal debugging"?

Imagine running Emacs under GDB and stopping at some breakpoint to debug
whatever. You want to xbacktrace and then proceed with continue. That
xbacktrace should not put MPS in post-mortem state.

> In any case, I asked about the downsides of calling igc_postmorten,
> which I think is crucial to understand for making this decision.  If
> there are no significant downsides, then doing so is a net win, no?

It's post-mortem = after death. MPS is then not in a usable state anymore.