From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Correct byte compiler error/warning positions. The solution! Date: Tue, 21 Dec 2021 17:48:26 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37781"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 21 18:49:48 2021 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 1mzjGk-0009av-Ma for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Dec 2021 18:49:46 +0100 Original-Received: from localhost ([::1]:36846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzjGj-0001kc-51 for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Dec 2021 12:49:45 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzjFi-0000s0-2U for emacs-devel@gnu.org; Tue, 21 Dec 2021 12:48:43 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:24039 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mzjFf-0006t2-J7 for emacs-devel@gnu.org; Tue, 21 Dec 2021 12:48:41 -0500 Original-Received: (qmail 39514 invoked by uid 3782); 21 Dec 2021 17:48:26 -0000 Original-Received: from acm.muc.de (p4fe15543.dip0.t-ipconnect.de [79.225.85.67]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 21 Dec 2021 18:48:26 +0100 Original-Received: (qmail 7585 invoked by uid 1000); 21 Dec 2021 17:48:26 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de 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_NONE=0.001, SPF_PASS=-0.001 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:282610 Archived-At: Hello, Andrea. On Mon, Dec 20, 2021 at 08:24:00 +0000, Andrea Corallo wrote: > Alan Mackenzie writes: [ .... ] > > I now have another problem, and that's when bootstrap-emacs is trying to > > load comp.{el,elc,eln} (I'm not sure which), and is in the (defconst > > comp-known-func-cstr-h ...). The (Lisp) backtrace I see looks like this: [ .... ] > > The error seems to mean there was an attempt to write into pure memory, > > and that the thing being written was the cl-block tag generated by the > > (cl-defun comp-cstr-union-1-no-mem ...). > > I thought I'd traced it to the `setcdr' form in cl--block-throw (in > > cl-macs.el), but when I tried commenting out the CHECK_IMPURE test from > > Fsetcdr (in data.c), I still got the same error and backtrace. > > Would you help me with this error, please. Thanks! > I suspect the error we see here is indeed induced by the code newly > introduced but is non sufficiently directly connected with it to > understand what's the issue there. > What I do suggest is that you bootstrap a non native compiled Emacs but > with native compilation support. Then you use this to native compile a > simple eln that leverage your new generated code. Note that with > native-comp-debug >= 2 you should be able to step into the eln with the > debugger. > To bootstrap a non native compiled Emacs but with native compilation > support one has to manually hack the /lisp/Makefile.in to have it > produce always and only .elc files instead of the .eln (IIRC two rules > have to be touched.). > Another alternative approach might be using your temacs to produce and > debug your eln to be tested. > Note: in both cases you will also have to set > `native-comp-deferred-compilation' to nil to avoid jit compilations. I've managed to nail this problem. I got bootstrap-emacs into gdb, with a breakpoint at pure_write_error3 (a variant of pure_write_error). In the backtrace, code-cstr-union-1-no-mem thought it was calling push_handler, but was actually calling pure_write_error. In my confusion, I had added entries to helper_link_table and also in declare_runtime_imported_funcs, but the two were not in sync. There was no comment saying that these two structures had to be kept matching eachother. Now that I've fixed that, I've got deep into a make bootstrap, but haven't quite managed to complete it. After that, there are quite a few things to tidy up. So, I think I'm going to finish it soon, but probably not before Christmas. Cheers! > Best Regards > Andrea > -- > akrl@sdf.org -- Alan Mackenzie (Nuremberg, Germany).