From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: pdumper on Solaris 10 Date: Sun, 15 Dec 2024 12:09:33 +0000 Message-ID: <87h675du7m.fsf@protonmail.com> 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> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30651"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Paul Eggert , gerd.moellmann@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 15 13:21:58 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 1tMndG-0007qh-27 for ged-emacs-devel@m.gmane-mx.org; Sun, 15 Dec 2024 13:21:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tMncO-0007xm-Go; Sun, 15 Dec 2024 07:21:04 -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 1tMnRW-00070f-I2 for emacs-devel@gnu.org; Sun, 15 Dec 2024 07:09:50 -0500 Original-Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tMnRT-0007vk-Uy for emacs-devel@gnu.org; Sun, 15 Dec 2024 07:09:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1734264577; x=1734523777; bh=tWs51I36Ln+PqTjJzL7Fc15Mgg5Ozvxw/ySkbjP91Bc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=c4/VHD7e6qppIbRTKESDduwcAvntRnJgMwXNMxjA8tVmEMDov2b8JItER4b8VuGz9 mTROMQny0vHtk4KJDDL5HYLf8oFuKJ/Vt2VGOrEnxBiJ7XjPuko6VashGbVqWzO/+/ rflXotJRaSIj064j1AcZ9Tn9mV76g/L+ex1nlFFeBbSUjusBpgNzMMABiRtS2iS1Ab ehguTNe4FoyyeamgeKp60+JpQZTv4Jex1I5J9+IXGqlh5s3Tt7pCX0vRSzTn9phFnD mbOiQzBruTLpr/jaW7Wloap6PEdVgWcDIGI2ECGfGwlEe5LsDxrc+Sjp1wmoTBfFF8 MD0YJX549r3nw== In-Reply-To: <86a5cxryfp.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0bd91bfd5333dee22c54f755668d896d538d6fcd Received-SPF: pass client-ip=185.70.40.131; envelope-from=pipcet@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -22 X-Spam_score: -2.3 X-Spam_bar: -- X-Spam_report: (-2.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_MSPIKE_H2=-1.168, 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-Mailman-Approved-At: Sun, 15 Dec 2024 07:21:03 -0500 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:326527 Archived-At: "Eli Zaretskii" writes: >> Date: Sun, 15 Dec 2024 10:55:49 +0000 >> From: Pip Cet >> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org >> >> "Eli Zaretskii" writes: >> >> > CC igc.o >> > igc.c: In function 'weak_hash_table_entry': >> > igc.c:4102:16: warning: cast to pointer from integer of different si= ze [-Wint-to-pointer-cast] >> > 4102 | client =3D (mps_addr_t)entry.intptr; >> > =09| ^ >> > igc.c:4107:16: warning: cast to pointer from integer of different si= ze [-Wint-to-pointer-cast] >> > 4107 | client =3D (mps_addr_t)real_ptr; >> > =09| ^ >> > >> > 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