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: Fri, 17 Dec 2021 11:54:25 +0000 Message-ID: References: <834k7ss172.fsf@gnu.org> 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="38256"; 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 Fri Dec 17 12:55:24 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 1myBpb-0009lu-IG for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Dec 2021 12:55:23 +0100 Original-Received: from localhost ([::1]:44548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1myBpZ-00046N-QA for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Dec 2021 06:55:21 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1myBol-0003QU-1E for emacs-devel@gnu.org; Fri, 17 Dec 2021 06:54:31 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:21279 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1myBoi-0001sJ-SW for emacs-devel@gnu.org; Fri, 17 Dec 2021 06:54:30 -0500 Original-Received: (qmail 29656 invoked by uid 3782); 17 Dec 2021 11:54:26 -0000 Original-Received: from acm.muc.de (p4fe154d4.dip0.t-ipconnect.de [79.225.84.212]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 17 Dec 2021 12:54:26 +0100 Original-Received: (qmail 7667 invoked by uid 1000); 17 Dec 2021 11:54:25 -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:282207 Archived-At: Hello, Andrea. On Wed, Dec 15, 2021 at 09:33:45 +0000, Andrea Corallo wrote: > Alan Mackenzie writes: [ .... ] > > I have a problem at the moment, which could be a big problem. How do I > > refer to a Lisp variable from jit generated code? > > In particular, I need read-access to symbols-with-pos-enabled, or more > > precisely to globals.f_symbols_with_pos_enabled. [ .... ] > > I tried declaring "globals" as a global variable to be imported into jit > > space, but the loader doesn't know about "globals". > > So, how can I get access to globals.f_symbols_with_pos_enabled? > > Thanks in advance! > Hi Alan, > I think the way should be done is that one declare in the .eln a global > variable as a (bool *), say 'f_symbols_with_pos_enabled_ref'. Then > during eln load time we set into that the correct address of > 'globals.f_symbols_with_pos_enabled' so it can be used as > '*f_symbols_with_pos_enabled_ref' by the generated code. 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. :-) > 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! > Best Regards > Andrea -- Alan Mackenzie (Nuremberg, Germany).