[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.
- Re: pdumper on Solaris 10, (continued)
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/10
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/10
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/10
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/10
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/10
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/10
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/10
- Re: pdumper on Solaris 10, Gerd Möllmann, 2024/12/10
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/11
- Re: pdumper on Solaris 10, Eli Zaretskii, 2024/12/11
- Re: pdumper on Solaris 10,
Eli Zaretskii <=
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/09
- Re: pdumper on Solaris 10, Pip Cet, 2024/12/08
- Re: pdumper on Solaris 10, Po Lu, 2024/12/08
- Re: pdumper on Solaris 10, Po Lu, 2024/12/08
Re: pdumper on Solaris 10, Po Lu, 2024/12/08
Re: pdumper on Solaris 10, Po Lu, 2024/12/08