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: Correct byte compiler error/warning positions. The solution! Date: Mon, 20 Dec 2021 08:24:00 +0000 Message-ID: References: <834k7ss172.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="31915"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 20 17:48:45 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 1mzLq9-00087C-Pu for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Dec 2021 17:48:45 +0100 Original-Received: from localhost ([::1]:59916 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzLq8-0008TR-Rs for ged-emacs-devel@m.gmane-mx.org; Mon, 20 Dec 2021 11:48:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKNg-0000Kl-9B for emacs-devel@gnu.org; Mon, 20 Dec 2021 10:15:22 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:61719) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzKMy-0002PL-Mu; Mon, 20 Dec 2021 10:15:06 -0500 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 1BK8O0aR010648 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 20 Dec 2021 08:24:01 GMT In-Reply-To: (Alan Mackenzie's message of "Fri, 17 Dec 2021 11:54:25 +0000") 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 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:282515 Archived-At: Alan Mackenzie writes: [...] > Thanks, I have done this, and have thus progressed further. It is a > shame we need the extra indirection, but it shouldn't cost too much in > run time. > > By the way, congratulations on using three stars in the declaration > struct thread_state ***current_thread_reloc;. That's not something one > sees very often. :-) Well... I'm a *** programmer :D :x >> We do something very similar for the Emacs global var 'current_thread'. >> In the eln we have a global variable named "current_thread_reloc" where >> we store the address of 'current_thread'. You can see we set this value >> during eln load in 'load_comp_unit'. > >> Just grep CURRENT_THREAD_RELOC_SYM and you should find the relevant >> pieces of code you are interested in. > > Done. > > 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: > > Debugger entered--Lisp error: (error "Attempt to modify read-only object" --cl-block-comp-cstr-union-1-no-mem--) > comp-cstr-union-1-no-mem(t #s(comp-cstr :typeset (number) :valset nil :range nil :neg nil) #s(comp-cstr :typeset (marker) :valset nil :range nil :neg nil)) > comp-cstr-union-1(t #s(comp-cstr :typeset (t) :valset nil :range nil > :neg nil) #s(comp-cstr :typeset (number) :valset nil :range nil :neg > nil) #s(comp-cstr :typeset (marker) :valset nil :range nil :neg nil)) > comp-cstr-union(#s(comp-cstr :typeset (t) :valset nil :range nil > :neg nil) #s(comp-cstr :typeset (number) :valset nil :range nil :neg > nil) #s(comp-cstr :typeset (marker) :valset nil :range nil :neg nil)) > comp-cstr-union-make(#s(comp-cstr :typeset (number) :valset nil :range nil :neg nil) #s(comp-cstr :typeset (marker) :valset nil :range nil :neg nil)) > comp-type-spec-to-cstr((or number marker) t) > #((or number marker)) > comp-type-spec-to-cstr((function ((or number marker) (or number marker)) number)) > byte-code("\302 > \30\303\304\305\"\11\306\211\211\211\211\5:\2038\0\5@\262\3\2\211A\262\4\242\262\5\2@\262\4\307\4!\262\2\310\5\3\6\11#\210\5A\262\6..." > [comp-ctxt comp-known-type-specifiers make-comp-cstr-ctxt > make-hash-table :test eq ni\l comp-type-spec-to-cstr puthash] 11) > (defconst comp-known-func-cstr-h (byte-code "\302 > \30\303\304\305\"\11\306\211\211\211\211\5:\2038\0\5@\262\3\2\211A\262\4\242\262\5\2@\262\4\307\4!\262\2\310\5\3\6\11#\210\5A\262\6..." > [comp-ctxt comp-known-type-specifiers make-comp-cst\r-ctxt > make-hash-table :test eq nil comp-type-spec-to-cstr puthash] 11) "Hash > table function -> `comp-constraint'.") > load("comp" nil t) > > 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. Best Regards Andrea >> Best Regards > >> Andrea -- akrl@sdf.org