From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: Loading tramp for dump goes into infinite regress Date: Mon, 25 Jul 2022 20:11:14 +0000 Message-ID: References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22487"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , michael.albinus@gmx.de, emacs-devel To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 25 22:12:47 2022 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 1oG4Ra-0005hi-BD for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 22:12:46 +0200 Original-Received: from localhost ([::1]:49906 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oG4RY-00069u-Tg for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Jul 2022 16:12:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38588) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oG4QL-0005Jw-Ll for emacs-devel@gnu.org; Mon, 25 Jul 2022 16:11:29 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:62893) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oG4QI-0006D4-T3; Mon, 25 Jul 2022 16:11:29 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 26PKBD0C011983 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 25 Jul 2022 20:11:14 GMT In-Reply-To: (Lynn Winebarger's message of "Mon, 25 Jul 2022 08:49:27 -0400") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org 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, 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" Xref: news.gmane.io gmane.emacs.devel:292653 Archived-At: Lynn Winebarger writes: > On Sun, Jul 24, 2022 at 12:31 PM Eli Zaretskii wrote: >> >> > From: Lynn Winebarger >> > Date: Sun, 24 Jul 2022 12:20:47 -0400 >> > Cc: michael.albinus@gmx.de, emacs-devel@gnu.org >> > >> > it seems like something undesirable is going on between dumping and >> > the native compilation unit. >> >> I find this hard to believe. > > If I can recreate it in a more direct way on my personal machines, I'll put in a bug with details including the required > modifications to tramp.el (to remove the problematic require of tramp-loaddefs). > I also observed the same problem/fix with: > gnus/message > progmodes/gdb-mi > calc/calc-ext > gnus/gnus-sum > gnus/gnus-art > More troublesome, though is that emacs segfaulted when it attempted to load nxml/rng-pttrn, whether loading > native-compiled, byte-compiled, or source. > > Otherwise, I was able to resolve the various issues (including some extensive surgery on vc/ediff-X files to stamp out > the circular loading). I am going to have to do a real bootstrap to avoid the "incoherent eln" error, though, and > somehow force native compilation for all the libraries loaded in the dump (that are not on the compiler's "forbidden" > list, anyway). > >> Btw, you are aware that dumping *.eln files basically dumps just their >> names, not their code? And that, when you start Emacs after dumping, >> it will load all of those *.eln files one by one, which takes time >> (*.eln files are just shared libraries, like *.so files), and use up >> shared-library and handle slots of the Emacs process? So I'm not even >> sure doing this would make sense from the performance POV: it could be >> that startup will slower, not faster. > > I am aware that dumping the eln files produces an indirection to the shared library, but not the details of the > implementation. > I would expect (or at least hope) that the effect of the evaluation that is done on loading to be stored in the dump and > for the shared libraries to get loaded into the process without repeating the evaluation. So things like the order of > customization groups should be fixed. While resurrecting from a dump an eln is mapped into memory if (at least) a native compiled function noted in the dump was loaded from it. So yeah the dumped state is preserved a no top level re-evaluation is happening. BTW I think so far we do not support re-dumping Emacs twice with native code. This is not a deep technical limitaiton, it's only because how we fixup relative eln paths to support installed and non installed builds, we should probably work on this limitation... BR Andrea