Re: pdumper on Solaris 10

[John ff <jpff@codemist.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 3775 bytes --]



⁣​

On 15 Dec 2024, 12:23, at 12:23, "Pip Cet via Emacs development discussions." <emacs-devel@gnu.org> wrote:
>"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

[-- Attachment #2: Type: text/html, Size: 5258 bytes --]