From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Loading tramp for dump goes into infinite regress Date: Sun, 31 Jul 2022 16:22:56 -0400 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: multipart/alternative; boundary="000000000000d3dcc605e51fa651" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34682"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Michael Albinus , emacs-devel To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 31 22:24:40 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 1oIFUN-0008pY-Td for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Jul 2022 22:24:40 +0200 Original-Received: from localhost ([::1]:43538 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIFUM-0002Zm-Ls for ged-emacs-devel@m.gmane-mx.org; Sun, 31 Jul 2022 16:24:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41336) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIFT0-0001lt-0d for emacs-devel@gnu.org; Sun, 31 Jul 2022 16:23:14 -0400 Original-Received: from mail-pf1-x42e.google.com ([2607:f8b0:4864:20::42e]:40933) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oIFSx-0007Bq-4w; Sun, 31 Jul 2022 16:23:12 -0400 Original-Received: by mail-pf1-x42e.google.com with SMTP id y141so8854744pfb.7; Sun, 31 Jul 2022 13:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MPCOQ8BDqEkK1sp7jw/wkKkXD6nqs0f7mzVGkoBxkjI=; b=VYTJ1HsSff9k2uNKSlcrSRAZGlaM/43BD7WToYe/gUffSNp6YJDCWzLeCBak5um2iD zmlJ5p6YU2pSGypIhg75+d+l7ZE4JVxwtpOyDzTpmB+4OZ/bfTvHANPcbCb6ItB8sd6B NMom06S2QmDs3kSLCZBaXCSw5yjem4vKNLJgNfQiGKC/yF55E/NtKCYmj1BQirsnvNbJ AAUn+fWs4DBytLr3mJ0g4EkQwsVfkTw/rJQfWE1BwGh6DnmZECEIP8OzTdCR1ICdzp7E 3+64jlmB8jaLGbrzzbTDdtaW+SCVleMS4y6JtFLn50qIbxqMQ17X2nKwkYubYBl1TCZW XcTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MPCOQ8BDqEkK1sp7jw/wkKkXD6nqs0f7mzVGkoBxkjI=; b=RITm9xD/4Dgu/DUJZBvG0sY4AK2D9YhCl6lWVPNQNz0d6zzZk2sc3sUBJAPKnysGaS OCmS/yKS57s4wr1NP8a56KFen1kEhpNkhf+rdfd6tFKgTso59FdbTGNjsyoF0PR02gCX mesoRwSRnLd4YxvQzJfXPJJbVZF9y447eQwds1b/3Vi02nljQwk00TU/LE5EZtIyqS0t 1yDIv5ItnrPUY1l6/ET5X62m/hLRvEKNDvo/LflfwENfmXcymFN4watljLJpMq/AH02J P5nmw3xNBwiQGeg5m3AJDRnm/DoyC32UmkILojlWNi41dAolh17txLT+mDXBGrkGWSEf /yTg== X-Gm-Message-State: ACgBeo0EWTYpJwigX2Ntc/spRzpTnI9gJMDgErkF7lv74WU2iqK4CtzX WgUpW5e+leaupcRAvufrQTP1jxynw3mTWwA0GDk= X-Google-Smtp-Source: AA6agR7OOwscqsNyWlJvHef56R7l/4Yp8S5LIga9JZVifjZyVDMWOlc0ji0xcAQHNmXGAyHa+6wfqQptAm7pzUR0/0E= X-Received: by 2002:aa7:8f0a:0:b0:52d:8135:64e0 with SMTP id x10-20020aa78f0a000000b0052d813564e0mr1310999pfr.0.1659298989200; Sun, 31 Jul 2022 13:23:09 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::42e; envelope-from=owinebar@gmail.com; helo=mail-pf1-x42e.google.com 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:292924 Archived-At: --000000000000d3dcc605e51fa651 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 25, 2022, 4:11 PM Andrea Corallo wrote: > Lynn Winebarger writes: > > > > 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... I still can't figure out why building with native compilation and a site-load file was producing an error about trying to load an incoherent ELN file. Now that I have a shell script for running make to compile the included files during the evaluation of site-init, I'm going to attempt that build again. One thing I might do is expose the "all_loaded_comp_units_h" variable in lisp, so I can check whether all the ELN files were actually loaded and compare that list against the one computed in loadup based on identifying native subrs bound to function symbols. That would provide a sanity check during the dump. It might be better to just explicitly base the mapping on that hash table directly just to ensure no loaded compilation units are missed while dumping. Lynn --000000000000d3dcc605e51fa651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 25, 2022, 4:11 PM Andrea Corallo <akrl@sdf.org> wrote:
Lynn Winebarger <owinebar@gmail.com> writes:



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.=C2=A0 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...

I still can't figure out why b= uilding with native compilation and a site-load file was producing an error= about trying to load an incoherent ELN file.=C2=A0=C2=A0
Now that I have a shell script for running make to compile the includ= ed files during the evaluation of site-init, I'm going to attempt that = build again.=C2=A0=C2=A0
One thing I might do is exp= ose the "all_loaded_comp_units_h" variable in lisp, so I can chec= k whether all the ELN files were actually loaded and compare that list agai= nst the one computed in loadup based on identifying native subrs bound to f= unction symbols.=C2=A0 That would provide a sanity check during the dump.= =C2=A0 It might be better to just explicitly base the mapping on that hash = table directly just to ensure no loaded compilation units are missed while = dumping.

Lynn



--000000000000d3dcc605e51fa651--