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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Mon, 8 Mar 2021 14:27:19 +0000
> Cc: Andrea Corallo <akrl@sdf.org>, 46256@debbugs.gnu.org, 
> andrewjmoreton@gmail.com
> 
> 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?