From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Mon, 8 Mar 2021 20:53:02 +0000 Message-ID: References: <86eehujcip.fsf@gmail.com> <86blch14qt.fsf@gmail.com> <83h7m84h9g.fsf@gnu.org> <86v9ao5czu.fsf@gmail.com> <86wnutogrh.fsf@gmail.com> <86wnut8fb9.fsf@gmail.com> <861rd1tbpa.fsf@gmail.com> <83pn0km6y3.fsf@gnu.org> <86ft1f8ara.fsf@gmail.com> <83sg5cjdn8.fsf@gnu.org> <83r1kwjcy2.fsf@gnu.org> <8335x6u9o4.fsf@gnu.org> <83zgzesrku.fsf@gnu.org> <83tupms4mp.fsf@gnu.org> <83eegpspjk.fsf@gnu.org> <83pn09qzsg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1987"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com, Andrea Corallo To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 08 21:54:35 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lJMtf-0000P6-JJ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 21:54:35 +0100 Original-Received: from localhost ([::1]:45086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJMtd-0004Tx-W1 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Mar 2021 15:54:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40624) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJMt9-0004RN-4u for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 15:54:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33468) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJMt8-00028c-7w for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 15:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJMt8-0002jC-6g for bug-gnu-emacs@gnu.org; Mon, 08 Mar 2021 15:54:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Mar 2021 20:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46256 X-GNU-PR-Package: emacs Original-Received: via spool by 46256-submit@debbugs.gnu.org id=B46256.161523682610465 (code B ref 46256); Mon, 08 Mar 2021 20:54:02 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 8 Mar 2021 20:53:46 +0000 Original-Received: from localhost ([127.0.0.1]:45014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJMsr-0002ii-KK for submit@debbugs.gnu.org; Mon, 08 Mar 2021 15:53:45 -0500 Original-Received: from mail-oi1-f178.google.com ([209.85.167.178]:45857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJMsq-0002iS-0D for 46256@debbugs.gnu.org; Mon, 08 Mar 2021 15:53:44 -0500 Original-Received: by mail-oi1-f178.google.com with SMTP id t83so2498949oih.12 for <46256@debbugs.gnu.org>; Mon, 08 Mar 2021 12:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n7WLwJUvMF5NqvfU6t3wkosKvcaHBkn1rrDTpLm2Wqg=; b=j7GX5LxdPk9/JgJgAwfNb9s/psOfQgoX+ttOCeoLOjTyynUjc6ev6mUWfo5Gp+s4FQ Mq2fP+Bz77mKwQUppYKnvH+v53LDlw7z5XadhFa+FTP4sgGaHcsOJzAKeMlwmhKxjBGe ItKX8v6Tbg1gVh2KoUgl2usdz8kZmNAXJx8eAmTbsA4Ru9JPkkBEGEcvLcabSaucpAns s6v1q3HCpkyNsgsWgSGIqVFr/54R42n7ASrSi3jiO77MHZyPb1dfElM0VK70Y5HWHa4r svt7NVx6JkmFJ9ayacwGmukPXo6ymi8BdZZGn1WGoz9//sngUF96Z/rK2GzETSjgH/7Z Xrrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n7WLwJUvMF5NqvfU6t3wkosKvcaHBkn1rrDTpLm2Wqg=; b=YwxAS7wVMOXI8UMJkJD3g7lHuz3zWszu/ZrBAZ0x8zDZYg9E4+y28K4GTm23ig3Uth wGnnhTF3PnhknTg2LPSOgdIRWPnZ8KryBTqaqwqP2KpMPXia49+JPNg+CK6g/h2uk5jA h0hpDcGG8f1r2KRmgaPlauLTNlh3uR1OJF0PD4OsKA0dZ/Febhjyr1I0bNT46O3g6Mmo ydJh6503+2rEoGjVE/ASlwx8RJjNA15r7PAohP9AhnvkYpDjT7FnbL5C+vThI+iEnk6e CTVZyGo1wIeCr4G2kJyv1FscNd8wMiiohfc29hSN//yhiyKYgrM5aGtU2iUTxjxI47mU XAuw== X-Gm-Message-State: AOAM532sHPO1+UQKcdbVMH5Sesxw5z1ks+u2MSerOCFfbYXLxB9wLYPB OmnfT9vm2cm+TjMufCNZU91ic00BgWi0n0zthK8= X-Google-Smtp-Source: ABdhPJzzF/l+ZMql2mA9XI0rf4+VwYUuK5ZD5MHpVNaCp/If+J1jppRpGEBrXFw1q0Qs0iv21lyPgJ+XeoNuvKUkgTQ= X-Received: by 2002:a54:4196:: with SMTP id 22mr582353oiy.30.1615236818535; Mon, 08 Mar 2021 12:53:38 -0800 (PST) In-Reply-To: <83pn09qzsg.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:201887 Archived-At: On Mon, Mar 8, 2021 at 6:13 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Mon, 8 Mar 2021 14:27:19 +0000 > > Cc: Andrea Corallo , 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. 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