From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Pure space Date: Sat, 17 Aug 2024 17:12:40 +0300 Message-ID: <86wmkf1bmv.fsf@gnu.org> References: <87cym8jngk.fsf@protonmail.com> <864j7j65b1.fsf@gnu.org> <87v7zzk1lf.fsf@yahoo.com> <8634n32tuw.fsf@gnu.org> <87y14vi849.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13233"; mail-complaints-to="usenet@ciao.gmane.io" Cc: stefankangas@gmail.com, pipcet@protonmail.com, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 17 16:13:32 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 1sfKBQ-0003J0-93 for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Aug 2024 16:13:32 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sfKAf-0005nq-Od; Sat, 17 Aug 2024 10:12:45 -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 1sfKAd-0005nR-KO for emacs-devel@gnu.org; Sat, 17 Aug 2024 10:12:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sfKAd-00024J-3O; Sat, 17 Aug 2024 10:12:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=31bM0PRff93snfJqf3/UTaIKDMgo3RDFhSZFxtx0OzI=; b=Xl5eDMXwyQQ2 Xabqpe3d+wqf3LIJPpH07T5zBhAg25dDi3lsNYG2fNGLwnjiMvPXlzhtF5hur6a23djYMs3XgJ04Z xlu/Q0kasqE6K4OeGqc0fmPFU1T33if+1sXKVmzftkpAlU/YdeN2iWL0uaLGcDit8dMS+lbcv2V2c LT0P8NCXwcHAaZxeUio1T5ogUcCEBrkTF/db5BMEme/lMQpAPn+sJSWeu+Gu6eqPsuGCYmQ3RRn3p 3gXjBAqznuMufD6nn+krOcL+41gxYAz9bUqqVnFFWOjxTj1UGGuy8+HcPY3wEepWCJ15f9ASgFzhv m7cqlIkhhnOS64+hL+V4MQ==; In-Reply-To: <87y14vi849.fsf@yahoo.com> (message from Po Lu on Sat, 17 Aug 2024 21:36:38 +0800) 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:322854 Archived-At: > From: Po Lu > Cc: Stefan Kangas , pipcet@protonmail.com, > emacs-devel@gnu.org > Date: Sat, 17 Aug 2024 21:36:38 +0800 > > >> > Portable dumping doesn't function on Windows 98 or DOS. Please fix or > >> > implement pdumper on these two platforms first, or hack their unexec > >> > builds not to require pure space, which should not be terribly > >> > difficult. > >> > >> In my view, that's not a blocker for removing the unexec build. > > > > Agreed. > > The Windows 98 build is: it has many users and it is in a satisfactory > condition at present, so it would be a terrible regression. Then the interested users and developers should come forward and help us find and fix whatever causes the crashes. I have not seen any such users, with you being the single exception, for a long time. If you can get someone motivated to work with us on fixing pdumper.c on Windows 9X, please do, and let's take it from there. Such an effort will at least be an investment in the future. > It crashes 100% of the time, actually, not merely "too much", which I > can't investigate without a functioning gdb, and which is very much > against the spirit of the word "portable". Unless one of you are > willing to show me a GDB that is newer than Code::Blocks provides and > which groks recent DWARF debug info, I don't forsee any solution. There's such a thing as printf debugging. It is far from ideal, but it's doable. > > If we want to keep the MSDOS port, the way forward is to switch it to > > pdumper. There's already an implementation in pdumper.c that uses > > malloc and write instead of the missing mmap, it just was never tried > > with the MSDOS port. I don't see any reasons why it couldn't work. > > Why can't unexecoff be retained without pure space? Because Emacs never used this combination, and because no one has time or knowhow to debug the MSDOS port anymore (which still uses COFF debug info, which makes the job of finding a proper GDB even harder). I might be the last person who can do that, and I don't have time to do that seriously, when significant problems pop up. > There's also no reason against this enormously simpler solution It is simple source code wise, but it is not a solution, it is a problem. We never used Emacs that way, and I'm quite sure this will trigger strange bugs that I don't want us to need to debug. Keeping the MSDOS build alive means keeping it in good health. While the current code base has some significant number of years under its belt (although that, too, becomes smaller and smaller as years go by and more significant code changes are installed) the version without pure space was never used before.