From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: ali_gnu2@emvision.com Newsgroups: gmane.emacs.devel Subject: Solaris dldump (was: Pure space) Date: Sat, 17 Aug 2024 19:15:42 -0600 Message-ID: <6b0199db-60e3-4a41-8481-414688db0e18@emvision.com> References: <878qwuitbu.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2971"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 18 03:16:40 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 1sfUX9-0000c5-Js for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Aug 2024 03:16:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sfUWK-0001At-7q; Sat, 17 Aug 2024 21:15:48 -0400 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 1sfUWI-0001AZ-JM for emacs-devel@gnu.org; Sat, 17 Aug 2024 21:15:46 -0400 Original-Received: from fhigh3-smtp.messagingengine.com ([103.168.172.154]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfUWG-0002Ve-IK for emacs-devel@gnu.org; Sat, 17 Aug 2024 21:15:46 -0400 Original-Received: from phl-compute-01.internal (phl-compute-01.nyi.internal [10.202.2.41]) by mailfhigh.nyi.internal (Postfix) with ESMTP id 60ECD1150996; Sat, 17 Aug 2024 21:15:43 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Sat, 17 Aug 2024 21:15:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emvision.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1723943743; x=1724030143; bh=122Ajc/Em0aF6MLWYXMARsggAh4HhMdRd5Xi4L2O/BA=; b= qRNpYS2i+79X0xRccQXqbRKfqnxdzuktzIaqvMpfn2K68592ddpQh2gsK/fypjOV gKEMz8RKUw/ispX4Ij0UnP0DxqqOKI35PSJtAIBB2V7TkR8SogUf2D0vavjNBM+X buB5LyoWWKH9Os/QgDSRerF5W/BpBjty/YvznL/qY+tf0/QvT0jGRyzcGmi03VxV peKAnC2hEftkjbqFZ5dBs3hZWy00FtSb7YM7BXqOYIGarFhTUbvEoPm2djkDHqQq xbzNUZHaMr98n8XS2aDhKlQtkOVHDjxDmz416VX1QDNYqlKmyXN3CkfhfVjEPBU3 HdPRcqwr03OrOHZduAulcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1723943743; x= 1724030143; bh=122Ajc/Em0aF6MLWYXMARsggAh4HhMdRd5Xi4L2O/BA=; b=E LOSZoAm7EAC78nGs3JnpXHWbwDRGQnHJFQ9KYVCQJCikTmjmw54qX7+UYloLsjO3 EOTQ9UkiWMk23oIXhFFaIpr6yATaHu2Lb+eHA15Po78s1jAR2HDeHRPOENk9bjRB 9avmU8dzboiAOOtI8u/864gYIJ8x+96O+ZSS2PIQESRRqOOOK7c49LITH+v2JJ1U P6dqzE34JfCHXjujH4+IAehNcIcBY5tX1qS5JtwceYFBPvBPTVa4t1m0bzPk8/Wj z8Fu9PONZNhZxt/8li27Fw4CAXKy1R0pQYxmifPs5XG+zCM5Z/MxHyLcdYydr6bD H3DUgdHJyzvc5e57cteaw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudduuddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfg fuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomheprghlihgpghhnuhdvsegvmhhv ihhsihhonhdrtghomhenucggtffrrghtthgvrhhnpefgffeufffhieeijedutddtveeuff ekudetvdekvdejueekgeeljeelgeekjeffgfenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhipghgnhhuvdesvghmvhhishhiohhnrdgtoh hmpdhnsggprhgtphhtthhopedvpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehl uhgrnhhgrhhuoheshigrhhhoohdrtghomhdprhgtphhtthhopegvmhgrtghsqdguvghvvg hlsehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: ie0614658:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 17 Aug 2024 21:15:42 -0400 (EDT) Content-Language: en-US In-Reply-To: <878qwuitbu.fsf@yahoo.com> Received-SPF: pass client-ip=103.168.172.154; envelope-from=ali_gnu2@emvision.com; helo=fhigh3-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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:322877 Archived-At: On 8/17/24 6:10 PM, Po Lu wrote: > Hello Ali! > > I think you underestimate the number of programs using dldump. I've > seen both Perl 5 and GNU Make hacked to save state with dldump, on > Oracle Solaris, producing binaries that don't depend on the presence of > a state file and probably start faster as well. Meanwhile > pdumper-dumped binaries appear to crash in an x86 Solaris 10 zone, > though I don't really use this configuration and I'm not interested in > trying the portable dumper on sparc: > > core 'core' of 7021: ../../src/bootstrap-emacs -batch --no-site-file --no-site-lisp -f batc > 00007fffaf433dc2 ???????? () > 00007fffaf5eb3d7 ???????? () > 00007fffaf5ec590 ???????? () > 00007fffae3f351a _lwp_kill () + a > 00007fffae3981b9 raise () + 19 > 00000000008baf90 terminate_due_to_signal () + c0 > 000000000090236e ???????? () > 0000000000902334 deliver_thread_signal () + 74 > 00000000009023b0 deliver_fatal_thread_signal () + 10 > 00000000009024ef handle_sigsegv () + 4f > 00007fffae3edd16 __sighndlr () + 6 > 00007fffae3e25e2 call_user_handler () + 252 > 00007fffae3e280e sigacthandler () + ee > 00007fffaf5ea82d ???????? () > ffffffffffffffff ???????? () > 00000000009c77e7 lisp_align_malloc () + 4d7 > 00000000009c9dd2 make_float () + 42 > 00000000009d2e9d init_alloc () + d > 00000000008bd373 main () + bb3 > 00000000006d15ab ???????? () > Hello! Is that stack from the s10 zone? You're probably right that I don't know who is using dldump(), outside of emacs, but not to worry, it's not going away. It's a committed interface, so hard to remove, and at the same time, isn't causing any problems. Nonetheless, it's not our favored way to deploy emacs, and I wouldn't want anyone to think we prefer its use, or require it. We use pdumper on newer Solaris 11.4, both x86 and sparc, with no reported issues. I wasn't aware of the Solaris 10 zone problems (haven't seen any reports). If you end up looking at it, and think that the s10 zone is somehow at fault, please feel free to contact me offline. However, given that s10 is 20 years old, it wouldn't be unreasonable to drop it off the support tail. From discussions with Rainer Orth, who maintains gcc for Solaris, I believe that s10 support for gcc has ended, or is very close to ending. My personal opinion is that anyone happy to use a 20 year old OS should have no problem using an older gcc, or emacs, so it's not really the end of the road for those folks. >> There are open source variants of Solaris for whom I don't >> speak, but from what I know about our common code, they should >> not be any more stuck on unexec() than we are. pdumper really >> doesn't use any unix features that didn't exist decades ago. > > I don't believe we try to support Illumos. If Emacs should work, more > power to them, but they have bigger fish to fry when GCC exception > handling fails if an exception is raised the instant an object is > unmapped, prompting dl_iterate_phdr to return -1. I expect that we're both benefiting from your work anyway. Isn't emacs still largely C (not C++)? I wouldn't expect exception handling to be needed, so maybe it's OK. I do know that dl_iterate_phdr() is a relatively recent addition for us, and was done after the split, so that is a case where the code is not common. No doubt the fix for Illumos would not be difficult, if/when they get to it. Thanks! - Ali