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

Previous Next

Full log

Message #463 received at 46256 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 46256 <at> debbugs.gnu.org, andrewjmoreton <at> gmail.com,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#46256: [feature/native-comp] AOT eln files ignored if run
 from build tree
Date: Mon, 8 Mar 2021 20:53:02 +0000

On Mon, Mar 8, 2021 at 6:13 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Mon, 8 Mar 2021 14:27:19 +0000
> > Cc: Andrea Corallo <akrl <at> sdf.org>, 46256 <at> debbugs.gnu.org, andrewjmoreton <at> 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.

The high 32 bits have indeed been clobbered, because we allocated only
four bytes for this Lisp_Object.

And since you use MSB tags, I'm assuming 0x91b9000 was where the other
native comp unit used to live.

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

But keep in mind that the code managed to call dynlib_sym (handle,
COMP_UNIT_SYM) just fine, so I think there might simply be a 4KB
region at the beginning of the library that's not mapped directly from
the shared object.

My search engine skills are weak, but aren't Windows DLL base
addresses aligned to 64 KB? This really looks to me like the "base
address" in Windows isn't what GDB shows in the From column.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.