Re: pdumper on Solaris 10

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

Pip Cet <pipcet@protonmail.com> writes:
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>> That's not what Gerd says, AFAIU.  But if you are right, then how
>>> about making the WIDE_EMACS_INT configuration on the igc branch use
>>> USE_LSB_TAG in the HAVE_MPS code branch?  I can volunteer to test such
>>> a build, if that would help.
>
> Thanks for the offer.  I definitely think we should move away from
> USE_LSB_TAG=0 as much as possible, and if the only place where such a
> change would not be vetoed is scratch/igc + WIDE_EMACS_INT, we can at
> least fix it there.  If any issues arise, of course, it will be more
> difficult to ascertain whether they were caused by the USE_LSB_TAG
> change or the IGC changes themselves.
>
> So I'll push that change in a bit, unless someone objects.

Just pushed it to the scratch/igc branch. It shouldn't have any effect
on ordinary 64-bit builds; some of the code is to cater to the
hypothetical big-endian 32-bit use case, and technically the x86 MPS
weak pointer "optimization" could bite us again, but recent GCC does not
generate the precise instructions that MPS emulates, so I'll risk it.

As I've just explained, bug reports for the WIDE_EMACS_INT case will be
difficult to deal with, as there are two major changes; let's see what
happens, but I suspect we'll end up having to ask users to build a !MPS
+ USE_LSB_TAG + WIDE_EMACS_INT configuration.

Pip