From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John ff Newsgroups: gmane.emacs.devel Subject: Re: pdumper on Solaris 10 Date: Sun, 15 Dec 2024 19:54:10 +0000 Message-ID: <91edb1c6-2caf-4597-88c1-a915e822ab01@codemist.co.uk> References: <86wmg7bso1.fsf@gnu.org> <865xnrbh3r.fsf@gnu.org> <87bjxil35f.fsf@protonmail.com> <86seqqtjzb.fsf@gnu.org> <87o71ddxmf.fsf@protonmail.com> <86a5cxryfp.fsf@gnu.org> <87h675du7m.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----3YRVFQO6SEYP90GW994SE3ZAQJJF4B" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39300"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Android Cc: Eli Zaretskii ,Paul Eggert , gerd.moellmann@gmail.com,emacs-devel@gnu.org To: Pip Cet Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 15 20:56:04 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tMuii-000A1x-4Q for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Dec 2024 20:56:04 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMui8-0005H5-4q; Sun, 15 Dec 2024 14:55:29 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tMui4-0005Fu-0a for emacs-devel@gnu.org; Sun, 15 Dec 2024 14:55:24 -0500 Original-Received: from codemist.co.uk ([217.155.197.248]) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMui1-0006ae-2J; Sun, 15 Dec 2024 14:55:22 -0500 Original-Received: from [172.16.4.31] by codemist.co.uk with esmtp (Exim 4.97.1) (envelope-from ) id 1tMuhw-0000000008Y-1OCS; Sun, 15 Dec 2024 19:55:16 +0000 In-Reply-To: <87h675du7m.fsf@protonmail.com> X-Referenced-Uid: 406506 Thread-Topic: Re: pdumper on Solaris 10 X-Is-Generated-Message-Id: true X-ACL-Warn: No reverse lookup Received-SPF: pass client-ip=217.155.197.248; envelope-from=jpff@codemist.co.uk; helo=codemist.co.uk X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326533 Archived-At: ------3YRVFQO6SEYP90GW994SE3ZAQJJF4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 =E2=81=A3=E2=80=8B On 15 Dec 2024, 12:23, at 12:23, "Pip Cet via Emacs d= evelopment discussions=2E" wrote: >"Eli Zaretskii" = writes: > >>> Date: Sun, 15 Dec 2024 10:55:49 +0000 >>> Fr= om: Pip Cet >>> Cc: gerd=2Emoellmann@gmail=2Ecom,= emacs-devel@gnu=2Eorg >>> >>> "Eli Zaretskii" writes: >>>= >>> > CC igc=2Eo >>> > igc=2Ec: In function 'weak_hash_table_e= ntry': >>> > igc=2Ec:4102:16: warning: cast to pointer from integer of >d= ifferent size [-Wint-to-pointer-cast] >>> > 4102 | client =3D (mps= _addr_t)entry=2Eintptr; >>> > | ^ >>> > igc=2Ec:4107:16: = warning: cast to pointer from integer of >different size [-Wint-to-pointer-= cast] >>> > 4107 | client =3D (mps_addr_t)real_ptr; >>> > | = ^ >>> > >>> > The warnings are real, because mps_addr_t is a 'voi= d *', so a >32-bit >>> > data type, whereas entry=2Eintptr is EMACS_UINT, s= o an unsigned >64-bit >>> > type=2E >>> >>> Oh, sorry for causing those=2E = >>> >>> 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 >expresse= d >>> using a cast to mps_addr_t=2E So the code behaves correctly, but is = >>> incorrect because it causes a compiler warning=2E >> >> 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)=2E > >The bad news is that whi= le MPS works when Emacs is run normally in a >non-wide-int build, running E= macs in GDB does not work: the siginfo_t >information passed to the SIGSEGV= handler isn't preserved=2E Currently, >the --with-wide-int build infloops= rather than crashing or working, but >I can't attach a debugger, so I'll h= ave to learn how to trigger (and >find) a core dump on this system=2E > >It= 's possible this problem is an unavoidable vicious cycle: since >small inte= gers are easily confused with pointers on this system, more >objects are "a= mbiguously" recognized as reachable even though they >aren't actually reach= able; that causes more objects to be retained, >which causes more integer v= alues to be treated as potential pointers, >resulting in even more retained= objects, until finally we run out of >virtual memory=2E At least that wou= ld explain the 2 GB core file=2E=2E=2E > >>> What's the preferred way of av= oiding 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 th= e ignored bits by bitwise AND=2E > >Either way sounds good to me, and I exp= ect both ways will result in >future compiler warnings (hopefully, these fu= ture 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)=2E > >>> > However,= profiling doesn't work, whereas it did >>> > in the "normal" 32-bit build= =2E (Note that SIGPROF is emulated on >>> > Windows, so maybe that emulati= on somehow causes this problem when >wide >>> > ints are used with MPS=2E) = >>> >>> Thanks for letting me know! That certainly sounds like a regression= >we >>> should fix=2E What kind of problem are we talking about? > >> How= ever, I repeated the test now, and I see that the profile does >> work=2E = I guess yesterday wins my personal record of producing >> irreproducible re= sults: this one and the one with >> completion-at-point-functions in anothe= r discussion=2E >> >> Sorry for the noise=2E > >No problem at all, and than= k you! > >Pip ------3YRVFQO6SEYP90GW994SE3ZAQJJF4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On 15 Dec 2024, at 12:23, "Pip Cet via Emacs= development discussions=2E" <emacs-devel@gnu=2Eorg> wrote:
"Eli Zaretskii" =
<eliz@gnu=2Eorg> writes:

 Date: Sun, 15=
 Dec 2024 10:55:49 +0000
 From: Pip Cet <pipcet@protonmail=2Ecom><=
br> Cc: gerd=2Emoellmann@gmail=2Ecom, emacs-devel@gnu=2Eorg

 "Eli Za=
retskii" <eliz@gnu=2Eorg> writes:

     CC       igc=2Eo
   igc=2Ec: In function 'weak=
_hash_table_entry':
   igc=2Ec:4102:16: warning: cast to pointer from in=
teger of different size [-Wint-to-pointer-cast]
    4102 |       client =
=3D (mps_addr_t)entry=2Eintptr;
  |                ^
   igc=2Ec:4107:=
16: warning: cast to pointer from integer of different size [-Wint-to-point=
er-cast]
    4107 |       client =3D (mps_addr_t)real_ptr;
  |       =
         ^

 The warnings are real, because mps_addr_t is a 'void *',=
 so a 32-bit
 data type, whereas entry=2Eintptr is EMACS_UINT, so an uns=
igned 64-bit
 type=2E

 Oh, sorry for causing those=
=2E

 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 expre=
ssed
 using a cast to mps_addr_t=2E  So the code behaves correctly, but =
is
 incorrect because it causes a compiler warning=2E
 What about the (hypothetical) case of big-endian systems?

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

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: th=
e siginfo_t
information passed to the SIGSEGV handler isn't preserved=2E=
  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 tri=
gger (and
find) a core dump on this system=2E

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" r=
ecognized 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 object=
s, until finally we run out of
virtual memory=2E  At least that would ex=
plain the 2 GB core file=2E=2E=2E

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

 I'll defer to Paul (CC'ed), but my personal preference=
 is also to
 explicitly reset the ignored bits by bitwise AND=2E

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

 However, profiling doesn't w=
ork, whereas it did
 in the "normal" 32-bit build=2E  (Note that SIGPROF=
 is emulated on
 Windows, so maybe that emulation somehow causes this pr=
oblem when wide
 ints are used with MPS=2E)

 Thanks =
for letting me know! That certainly sounds like a regression we
 should =
fix=2E  What kind of problem are we talking about?

 However, I rep=
eated the test now, and I see that the profile does
 work=2E  I guess ye=
sterday wins my personal record of producing
 irreproducible results: th=
is one and the one with
 completion-at-point-functions in another discus=
sion=2E

 Sorry for the noise=2E

No problem at al=
l, and thank you!

Pip


------3YRVFQO6SEYP90GW994SE3ZAQJJF4B--