Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree

From: Eli Zaretskii <[email-masked]>
Date: Mon, 08 Mar 2021 20:06:58 +0200

> From: Pip Cet <[email-masked]>
> Date: Mon, 8 Mar 2021 14:27:19 +0000
> Cc: Andrea Corallo <[email-masked]>, [email-masked], [email-masked]
> 
> I would be interested in the pseudovector type of the variable that is
> supposed to be a comp_unit, but isn't. I think that's all the
> information of value that debuggee still has...

You mean, *saved_cu?  It cannot be anything interesting, because the
pointer is garbled:

  (gdb) p *saved_cu
  $9 = XIL(0x6f04860091b9000)
  (gdb) xtype
  Lisp_Symbol
  (gdb) xsymbol
  $10 = (struct Lisp_Symbol *) 0xaa21360
  Cannot access memory at address 0xaa21368

Since this is a 32-bit build, no Lisp object can have the high 24 bits
non-zero, so 0x6f04860091b9000 cannot be a valid object.

Another factoid that may be of interest is this.  At the beginning of
load_comp_unit we do:

  dynlib_handle_ptr handle = comp_u->handle;

So:

  (gdb) p/x comp_u->handle
  $13 = 0x6a580000

Now, on Windows, the "handle" returned by LoadLibrary is just the
memory address where the library is loaded.  However, "info shared" in
GDB doesn't show _any_ .eln library loaded at that address.  The
closest one is this:

  From        To          Syms Read   Shared Object Library
  0x6a581000  0x6a5bacd8  Yes         d:\usr\eli\.emacs.d\eln-cache\28.0.50-19fa14f1\cc-align-bb265728-bd3550a3.eln

whose address is 4KB higher.  That probably means the CU represented
by comp_u was unloaded, right?

Anything else we could glean from that crashed Emacs?