emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pdumper on Solaris 10


From: Eli Zaretskii
Subject: Re: pdumper on Solaris 10
Date: Sat, 14 Dec 2024 16:30:48 +0200

> Date: Wed, 11 Dec 2024 14:13:11 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, luangruo@yahoo.com, 
> ali_gnu2@emvision.com, 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.

Thanks, I've now built the igc branch --with-wide-int, and it compiled
cleanly, with the exception of these 2 warnings:

    CC       igc.o
  igc.c: In function 'weak_hash_table_entry':
  igc.c:4102:16: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
   4102 |       client = (mps_addr_t)entry.intptr;
        |                ^
  igc.c:4107:16: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
   4107 |       client = (mps_addr_t)real_ptr;
        |                ^

The warnings are real, because mps_addr_t is a 'void *', so a 32-bit
data type, whereas entry.intptr is EMACS_UINT, so an unsigned 64-bit
type.

I've started the produced Emacs and scrolled through a long file,
which seemed to work.  However, profiling doesn't work, whereas it did
in the "normal" 32-bit build.  (Note that SIGPROF is emulated on
Windows, so maybe that emulation somehow causes this problem when wide
ints are used with MPS.)

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]