Re: Correct byte compiler error/warning positions. The solution!

[Alan Mackenzie <acm@muc.de>]

Hello, Andrea.

On Wed, Dec 15, 2021 at 09:33:45 +0000, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> 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)
  #<subr F616e6f6e796d6f75732d6c616d626461_anonymous_lambda_51>((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).