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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

I guess this suggests 0x6a580000 was a previously infact a mapped eln
that got unmapped.

  Andrea