From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Tue, 09 Mar 2021 19:38:15 +0000 Message-ID: References: <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> <83r1kpr03h.fsf@gnu.org> <83mtvdqt53.fsf@gnu.org> <83blbsqyea.fsf@gnu.org> <83mtvcp4ac.fsf@gnu.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29587"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 46256@debbugs.gnu.org, andrewjmoreton@gmail.com, pipcet@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 09 21:37:25 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 1lJj6b-0007ad-OU for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Mar 2021 21:37:25 +0100 Original-Received: from localhost ([::1]:37816 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJj6a-0003NT-Lp for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Mar 2021 15:37:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJiC6-00076f-5k for bug-gnu-emacs@gnu.org; Tue, 09 Mar 2021 14:39:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36440) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJiC5-00055K-U1 for bug-gnu-emacs@gnu.org; Tue, 09 Mar 2021 14:39:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJiC5-0001R4-RB for bug-gnu-emacs@gnu.org; Tue, 09 Mar 2021 14:39:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Mar 2021 19:39:01 +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.16153187025471 (code B ref 46256); Tue, 09 Mar 2021 19:39:01 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 9 Mar 2021 19:38:22 +0000 Original-Received: from localhost ([127.0.0.1]:47986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJiBS-0001QA-DY for submit@debbugs.gnu.org; Tue, 09 Mar 2021 14:38:22 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:65040) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJiBN-0001Px-1d for 46256@debbugs.gnu.org; Tue, 09 Mar 2021 14:38:20 -0500 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 129JcFI3007092 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 9 Mar 2021 19:38:16 GMT In-Reply-To: <83mtvcp4ac.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 09 Mar 2021 20:31:39 +0200") 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:201942 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: pipcet@gmail.com, 46256@debbugs.gnu.org, andrewjmoreton@gmail.com >> Date: Tue, 09 Mar 2021 14:55:40 +0000 >> >> cc-*.el files for instance have more than one direct call to load. IIRC >> one of the analyzed cases was cc-mode related (certanly one I observed). >> >> >> > What are the reasons for unloading a .eln file which was once loaded >> >> > into a session? >> >> >> >> All the functions defined in it are not anymore reachable (read all >> >> symbols functions are makunbound or defined to some other function). >> > >> > That means someone did unload-feature, right? >> >> Also loading for example a new version freshly compiled of the same file >> should present the same scenario. > > I see a problem in this area. Consider this code in > native-elisp-load: > > if (!NILP (Fgethash (filename, all_loaded_comp_units_h, Qnil)) > && !file_in_eln_sys_dir (filename) > && !NILP (Ffile_writable_p (filename))) > { > /* If in this session there was ever a file loaded with this > name, rename it before loading, to make sure we always get a > new handle! */ > Lisp_Object tmp_filename = > Fmake_temp_file_internal (filename, Qnil, build_string (".eln.tmp"), > Qnil); > if (NILP (Ffile_writable_p (tmp_filename))) > comp_u->handle = dynlib_open (SSDATA (encoded_filename)); > else > { > Frename_file (filename, tmp_filename, Qt); > comp_u->handle = dynlib_open (SSDATA (ENCODE_FILE (tmp_filename))); > Frename_file (tmp_filename, filename, Qnil); > } > > The last 'else' branch momentarily renames the .eln file, then loads > it under the modified name, with the assumption that this would force > dynlib_open to produce a new handle. But in the case that the same > .eln file is loaded more than once, i.e. the .eln file was not > modified since the previous load, dynlib_open returns the same handle > regardless of the file name, at least on MS-Windows. (Does this work > as intended on GNU/Linux?) > > The problem with returning the same handle is that the refcount of the > handle is incremented, which means unload-feature will be unable to > unload the library. It works because the handle is stored into the new CU object and passed to 'load_comp_unit'. 'load_comp_unit' will recognize the "re-load" condition and discard the CU freshly allocated to use the original one (that is stored in the .eln). As a consequence the discarded CU will be GC'd end so the refcounf will be decremented. > Is this renaming dance for the case that the .eln file was updated > since the last load, or do we need it even if it wasn't updated? The renaming dance is for cases like one changes `comp-speed' recompile and load. Andrea