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

[Alan Mackenzie <acm@muc.de>]

Hello, Andrea.

On Mon, Dec 20, 2021 at 08:24:00 +0000, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> 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).