Re: pdumper on Solaris 10

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> 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.

Oh, sorry for causing those.

The intended behavior is to truncate the integer and use the 32 LSB
bits, which is safe on the machines MPS is ported to, and is expressed
using a cast to mps_addr_t.  So the code behaves correctly, but is
incorrect because it causes a compiler warning.

What's the preferred way of avoiding a compiler warning in this case?
A simple double cast (first to uintptr_t, then to mps_addr_t) should
work, right?

> I've started the produced Emacs and scrolled through a long file,
> which seemed to work.

Thank you for testing!

> 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 for letting me know! That certainly sounds like a regression we
should fix.  What kind of problem are we talking about?

If it's not reproducible on GNU/Linux (at first glance, the profiler
works fine in an i686 --with-wide-int configuration, but I don't know
what kind of problem you are experiencing), the next problem is that the
mingw32 (the OSDN kind, not the msys2 kind) toolchain is currently
unavailable (https://dl.osdn.net isn't responding at all right now,
rather than responding with an expired SSL certificate as it sometimes
does).

Pip