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: --with-native-compilation build failure on 32-bit systems Date: Mon, 8 Aug 2022 09:55:11 -0400 Message-ID: References: <86k07nl9qe.fsf@phe.ftfl.ca> <87bksyc36k.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d5f75a05e5bb2a43" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3328"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , Joseph Mingrone , emacs-devel , emacs@freebsd.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 16:03:55 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 1oL3MH-0000ar-OQ for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 16:03:53 +0200 Original-Received: from localhost ([::1]:42896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL3MG-00012U-9K for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 10:03:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL3EA-0001cy-Ez for emacs-devel@gnu.org; Mon, 08 Aug 2022 09:55:32 -0400 Original-Received: from mail-pl1-x62f.google.com ([2607:f8b0:4864:20::62f]:40614) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oL3E8-0003bz-CO for emacs-devel@gnu.org; Mon, 08 Aug 2022 09:55:30 -0400 Original-Received: by mail-pl1-x62f.google.com with SMTP id x23so8627902pll.7 for ; Mon, 08 Aug 2022 06:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=hz/yC79F0e1O0gk4+j7asKC3sxaANQmyF0qSHn5YD/s=; b=UtzJpTS89pQKP12HV15lbuYvIBQ3cvEJLdu0w0KAJZKm1kpv0CILz+52QmrjKKKE16 KlR0vtqAvUeb74Qv8Iy8xnM9gv9AXn9fQICFIjPmIEcvfOINE/3OMJ36PuVCws92tVcd xmyHuG/1qQv7/VgBCM5eIKv/ouKf8v5zjtZTb7wOkyrHfMWEVqHMjohE4vDB9rYTwS4h 0/UCI8EksVfSZ/b34PMHznfoZMJ/K5w9EDdZxnGFNNFSEvqEGMpOt9XZcvSEPakf+HLy 6JikVfterrzaK02YC/chi4H0zfQof62hcs9l+7VlHkDQQAfHduPV5p1t6QC1wbomvx2d 1dYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=hz/yC79F0e1O0gk4+j7asKC3sxaANQmyF0qSHn5YD/s=; b=Boo7pzMTs7CEC9QkKUUx2H35iSnrwRxFSv6h/2tq8J42MgmbOWlRUQAY42ugi2du0S QXkBw/bdRMtajHFVGFIU5Blf+SvPQcLMNSzJGulT/9p3Kbtr0tw9lBOu5cb163r2c5fY HyZ/TEHpjIqE1P12seTtQvbMRaS6HI27JU2VeEWzKIYqO7yU9GO9Et4ZLVaA03bPLHBN ce2KwWIlVmY3F7kgPWRs5AzXMcwck6mh2cQ/GL5Ih3qlIYprnZv0Dk5JWcTyq91r5TKh IngVU2JKAqsNxKJs58Icf3NITWG7zfkVssLBM+XVb5bdbzdgz7rSzdQrgJ0w7RDjlZfr 5G0g== X-Gm-Message-State: ACgBeo3lDCv403xfEryJjSwLf8tPZZLpQrawvaOL4pTH7urdFt46FC9d 4AouxKH7n0GVNldUxk46z+F4e7pp7tSz6adPFH8= X-Google-Smtp-Source: AA6agR7ZlNUKRo3DvYUUH6CxFhrMyrXZntTag0CHjDY3Cyup29mitz/SB74BWklljdF0kIFZHw76+gLmn5PosIOGaPw= X-Received: by 2002:a17:902:ab0b:b0:170:d51c:a667 with SMTP id ik11-20020a170902ab0b00b00170d51ca667mr306687plb.156.1659966923862; Mon, 08 Aug 2022 06:55:23 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::62f; envelope-from=owinebar@gmail.com; helo=mail-pl1-x62f.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:293264 Archived-At: --000000000000d5f75a05e5bb2a43 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 8, 2022, 9:14 AM Andrea Corallo wrote: > Lynn Winebarger writes: > > > On Mon, Aug 8, 2022, 3:44 AM Andrea Corallo wrote: > > > > Lynn Winebarger writes: > > > > > On Fri, Aug 5, 2022, 10:42 AM Andrea Corallo wrote: > > > > > > Andrea Corallo writes: > > > > > > > Lars Ingebrigtsen writes: > > > > > > > >> Joseph Mingrone writes: > > > >> > > > >>> Could 261d6af have broken --with-native-compilation builds on > 32-bit > > > >>> systems? This is what I see building in a clean FreeBSD/i386 > 13.0 > > > >>> jail using 261d6af: > > > >>> > http://pkg.ftfl.ca/data/13i386-default/2022-08-04_22h38m28s/logs/errors/emacs-devel-29.0.50.20220804,2.log > > > >> > > > >> I guess these are the error messages? > > > >> > > > >> emacs: Trying to load incoherent dumped eln file > > > >> > > > > > > /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-261d6af/native-lisp/29.0.50-7cc1a43d/preloaded/ediff-hook-0b92f1a2-f843c8a0.eln > > > > > > > > >> > > > >> I don't know what that means; Andrea added to the CCs. > > > > > > > > It's very surprising to see 261d6af causing this side effect, at > least I > > > > don't see why should effect the 32bit build only. > > > > > > > > I'm trying to reproduce it on my 32bit env. > > > > > > I confirm the build it's broken on my 32bit env as well, (but not on > the > > > 64 one). > > > > > > Loading the second dump, while we are relocating the ediff-hook > > > compilation unit, we realize (@ pdumper.c:5304) that its file field > is > > > not a cons as expected but just a string. > > > > > > Now the question is why this is not fixed-up in loadup.el:477 as for > the > > > other compilation units? > > > > > > Are you sure it's actually fixed up in the other compilation units? > > > > Indeed, otherwise an error is signaled. > > > > > This problem should be signaled by loadup if there are any NCUs it > does not fix up. It would be a lot easier to > > diagnose > > > the problem from there. > > > > loadup is in charge of fixing up on all CU's file fields, and indeed if > > something goes wrong in that code an error is signaled. But evidently > > this is not the case, so there's something more to understand. > > > > I just looked, and there are 2 possible paths for NCUs to be in the dump > without an error being signaled: > > 1 - either the --bin-dest or --eln-dest flag is not specified (or is > > on the command line but empty) > > This is not the case in our build. > No, but it is one way the dump can produce an unusable file without any error signaled until an Emacs instance attempts to load it. > > > 2 - there is an NCU loaded for which no symbol is bound to a subr in > that NCU. > > CUs that are not reachable from the function slot of a symbol are > unloaded when GC runs. We do run GC before dumping so this should not > happen. Yes, "should" is the operative word there. Why not validate the condition before writing the dump file? If not in loadup, then in the procedure that records the NCU in the dump? Why wait until load-time to catch something that was almost certainly (barring user performing surgery on the dump file) the case when the dump was produced? Just put the same check before the "write" operation that is done immediately after the corresponding "read" operation. Lynn --000000000000d5f75a05e5bb2a43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 8, 2022, 9:14 AM Andrea Corallo <akrl@sdf.org> wrote:
Lynn Winebarger <owinebar@gmail.com> writes:

> On Mon, Aug 8, 2022, 3:44 AM Andrea Corallo <akrl@sdf.org> wrote:<= br> >
>=C2=A0 Lynn Winebarger <owinebar@gmail.com> writes:
>
>=C2=A0 > On Fri, Aug 5, 2022, 10:42 AM Andrea Corallo <akrl@sdf.org= > wrote:
>=C2=A0 >
>=C2=A0 >=C2=A0 Andrea Corallo <akrl@sdf.org> writes:
>=C2=A0 >
>=C2=A0 >=C2=A0 > Lars Ingebrigtsen <larsi@gnus.org> writes:=
>=C2=A0 >=C2=A0 >
>=C2=A0 >=C2=A0 >> Joseph Mingrone <jrm@ftfl.ca> writes:
>=C2=A0 >=C2=A0 >>
>=C2=A0 >=C2=A0 >>> Could 261d6af have broken --with-native-= compilation builds on 32-bit
>=C2=A0 >=C2=A0 >>> systems?=C2=A0 This is what I see buildi= ng in a clean FreeBSD/i386 13.0
>=C2=A0 >=C2=A0 >>> jail using 261d6af:
>=C2=A0 >=C2=A0 >>> http://pkg.ftfl.ca/data= /13i386-default/2022-08-04_22h38m28s/logs/errors/emacs-devel-29.0.50.202208= 04,2.log
>=C2=A0 >=C2=A0 >>
>=C2=A0 >=C2=A0 >> I guess these are the error messages?
>=C2=A0 >=C2=A0 >>
>=C2=A0 >=C2=A0 >> emacs: Trying to load incoherent dumped eln = file
>=C2=A0 >=C2=A0 >>
>=C2=A0 >
>=C2=A0 /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-261d6af/n= ative-lisp/29.0.50-7cc1a43d/preloaded/ediff-hook-0b92f1a2-f843c8a0.eln
>=C2=A0
>=C2=A0 >=C2=A0
>=C2=A0 >=C2=A0 >>
>=C2=A0 >=C2=A0 >> I don't know what that means; Andrea add= ed to the CCs.
>=C2=A0 >=C2=A0 >
>=C2=A0 >=C2=A0 > It's very surprising to see 261d6af causing = this side effect, at least I
>=C2=A0 >=C2=A0 > don't see why should effect the 32bit build = only.
>=C2=A0 >=C2=A0 >
>=C2=A0 >=C2=A0 > I'm trying to reproduce it on my 32bit env.<= br> >=C2=A0 >
>=C2=A0 >=C2=A0 I confirm the build it's broken on my 32bit env a= s well, (but not on the
>=C2=A0 >=C2=A0 64 one).
>=C2=A0 >
>=C2=A0 >=C2=A0 Loading the second dump, while we are relocating the = ediff-hook
>=C2=A0 >=C2=A0 compilation unit, we realize (@ pdumper.c:5304) that = its file field is
>=C2=A0 >=C2=A0 not a cons as expected but just a string.
>=C2=A0 >
>=C2=A0 >=C2=A0 Now the question is why this is not fixed-up in loadu= p.el:477 as for the
>=C2=A0 >=C2=A0 other compilation units?
>=C2=A0 >
>=C2=A0 > Are you sure it's actually fixed up in the other compil= ation units?
>
>=C2=A0 Indeed, otherwise an error is signaled.
>
>=C2=A0 > This problem should be signaled by loadup if there are any = NCUs it does not fix up.=C2=A0 It would be a lot easier to
>=C2=A0 diagnose
>=C2=A0 > the problem from there.
>
>=C2=A0 loadup is in charge of fixing up on all CU's file fields, an= d indeed if
>=C2=A0 something goes wrong in that code an error is signaled.=C2=A0 Bu= t evidently
>=C2=A0 this is not the case, so there's something more to understan= d.
>
> I just looked, and there are 2 possible paths for NCUs to be in the du= mp without an error being signaled:
> 1 - either the --bin-dest or --eln-dest flag is not specified (or is > on the command line but empty)

This is not the case in our build.

No, but it is one way the dump can produc= e an unusable file without any error signaled until an Emacs instance attem= pts to load it.

> 2 - there is an NCU loaded for which no symbol is bound to a subr in t= hat NCU.

CUs that are not reachable from the function slot of a symbol are
unloaded when GC runs.=C2=A0 We do run GC before dumping so this should not=
happen.

Yes, "should" is the operative word th= ere.=C2=A0 Why not validate the condition before writing the dump file?=C2= =A0 If not in loadup, then in the procedure that records the NCU in the dum= p?=C2=A0 Why wait until load-time to catch something that was almost certai= nly (barring user performing surgery on the dump file) the case when the du= mp was produced?=C2=A0 Just put the same check before the "write"= operation that is=C2=A0 done immediately after the corresponding "rea= d" operation.

Lynn<= /div>


--000000000000d5f75a05e5bb2a43--