From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.devel Subject: Re: Solaris dldump Date: Mon, 19 Aug 2024 13:46:11 +0000 Message-ID: <87bk1oeich.fsf@protonmail.com> References: <6b0199db-60e3-4a41-8481-414688db0e18@emvision.com> <87ttfihbbn.fsf@yahoo.com> <87h6bhgzc2.fsf@yahoo.com> <87plq4enze.fsf@protonmail.com> <87cym4hgil.fsf@yahoo.com> <87h6bgems9.fsf@protonmail.com> <86bk1oy8ns.fsf@gnu.org> 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="577"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, stefankangas@gmail.com, ali_gnu2@emvision.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 19 16:20:16 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 1sg3F1-000ATZ-MN for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Aug 2024 16:20:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sg3EY-0004ka-NC; Mon, 19 Aug 2024 10:19:46 -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 1sg2iE-0006qU-HQ for emacs-devel@gnu.org; Mon, 19 Aug 2024 09:46:23 -0400 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sg2iB-0003np-3a for emacs-devel@gnu.org; Mon, 19 Aug 2024 09:46:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724075175; x=1724334375; bh=jpMLuNxw/sIPHqiJ1EmvUxOYBHQGjn+nbnmn3cKGSpw=; 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; b=I3hI4E6Uc8QnQidttu7zEnQqxONluKcbTVu2C6ZoOpQ3gEPSrjZyE9zp6C+K5PBTR fiOOFbAJjmzMgC/cZcd0xHDnInA/ZNM1grotiPqKnVt/FMJJuQmBqOfpg46DO/I0dU XWFzZ5LYSqL0kWD7lL64MKHHTW82kVPetfnDlRw4rZP04EyUNKCa2/6tv2NV4xeZYs z1X+ZkJN63H/i4z2OW2eFFkyojmyZS1i5QBVOj29+Y0KUzm6ymYeJGMK62O27zr5hE LRPZjxwpmo18lUEXCO4pyJev9kjj3JhUpvM2g5GCSKSIWgL6QP4JC+dc2e0bYdPxJG g8gRRnSvGbJqA== In-Reply-To: <86bk1oy8ns.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8e37b02c2d6f61683766c5e5e54d52b3765352a0 Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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-Mailman-Approved-At: Mon, 19 Aug 2024 10:19:44 -0400 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:322921 Archived-At: "Eli Zaretskii" writes: >> Date: Mon, 19 Aug 2024 12:10:19 +0000 >> From: Pip Cet >> Cc: Stefan Kangas , ali_gnu2@emvision.com, >> emacs-devel@gnu.org >> >> "Po Lu" writes: >> > Pip Cet writes: >> >> Wait, I'm not sure I understand that part. How does removing pure sp= ace >> >> burden anyone with additional labor, hypothetical or not? >> > >> > Isn't this theoretical burden the reason that pure space is not to be >> > removed except along with unexec? >> >> Maybe a compromise would be to keep unexec but put it on probation, >> promising to remove it if problems arise that cannot be convincingly and >> immediately fixed? > > That'd just add to code churn and maintenance burden. So I prefer > removing it to begin with. I've just gone through configure.ac removing all the code that depends on unexec (no doubt I've missed some), and I must say I now agree it is time for unexec to go. In particular, it had so far escaped my attention that it's incompatible with native compilation! So I'll update the scratch/no-purespace branch to also remove unexec, and of course I'm offering to help anyone who wants to fix the remaining non-pdumper ports. And while I am skeptical of the value of ASLR, it wuold be really embarrassing to run into a security issue that's exploitable only because Emacs disables ASLR for unexec builds. >> > Anyway, I want pure space gone as much as any of us, I just don't agre= e >> > that taking unexec down with it is justified. Maybe the ELF, XCOFF, a= nd >> > Windows unexecs, but not the Solaris or DOS ones. >> >> DOS in particular is what triggered my question: given the limitations >> of DOS systems, it's quite possible temacs-as-emacs just wouldn't fly on >> those machines. > > Those limitations are not relevant in our case. I think it's relevant whether DOS will become completely unusable or merely difficult to use once unexec is removed, and what can be done to fix it. Does the DOS port work on free DOS clones? And is there a way to gain access to a Solaris machine to fix pdumper on it? Pip