Re: pdumper on Solaris 10

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

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

>> Date: Sun, 15 Dec 2024 10:55:49 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> >     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 about the (hypothetical) case of big-endian systems?

Not a problem here, but there is some good news concerning the
"hypothetical" part: I'm testing 32-bit builds on a sparc system, so
it's no longer hypothetical (thanks again to the cfarm people for giving
me an account).

The bad news is that while MPS works when Emacs is run normally in a
non-wide-int build, running Emacs in GDB does not work: the siginfo_t
information passed to the SIGSEGV handler isn't preserved.  Currently,
the --with-wide-int build infloops rather than crashing or working, but
I can't attach a debugger, so I'll have to learn how to trigger (and
find) a core dump on this system.

It's possible this problem is an unavoidable vicious cycle: since
small integers are easily confused with pointers on this system, more
objects are "ambiguously" recognized as reachable even though they
aren't actually reachable; that causes more objects to be retained,
which causes more integer values to be treated as potential pointers,
resulting in even more retained objects, until finally we run out of
virtual memory.  At least that would explain the 2 GB core file...

>> 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'll defer to Paul (CC'ed), but my personal preference is also to
> explicitly reset the ignored bits by bitwise AND.

Either way sounds good to me, and I expect both ways will result in
future compiler warnings (hopefully, these future compilers will also
have a better way of indicating that a cast from a 64-bit integer to a
32-bit pointer is intended here).

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

> However, I repeated the test now, and I see that the profile does
> work.  I guess yesterday wins my personal record of producing
> irreproducible results: this one and the one with
> completion-at-point-functions in another discussion.
>
> Sorry for the noise.

No problem at all, and thank you!

Pip