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

[Andrea Corallo]

Alan Mackenzie <acm@muc.de> 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)
>   #<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!

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