From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.devel Subject: Re: How does one find out what file a library has been loaded from? Date: Mon, 01 Aug 2022 09:23:05 +0000 Message-ID: References: <83bktlnuog.fsf@gnu.org> <83ilnmfq9t.fsf@gnu.org> <83ilnd4f72.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28627"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: acm@muc.de, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 01 11:24:32 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oIRf5-0007G6-R5 for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Aug 2022 11:24:31 +0200 Original-Received: from localhost ([::1]:40344 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oIRf4-0001R4-8Q for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Aug 2022 05:24:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIRdv-0000eL-C1 for emacs-devel@gnu.org; Mon, 01 Aug 2022 05:23:19 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:50021) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oIRdt-0001v9-1a; Mon, 01 Aug 2022 05:23:19 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 2719N5OA018466 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 1 Aug 2022 09:23:07 GMT In-Reply-To: <83ilnd4f72.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 31 Jul 2022 15:52:33 +0300") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292933 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: acm@muc.de, emacs-devel@gnu.org >> Date: Sun, 24 Jul 2022 17:46:02 +0000 >> >> >> (native-comp-unit-file (subr-native-comp-unit (symbol-function #'find-file))) >> > >> > Andrea, does anything similar to subr-native-comp-unit exists for >> > other types of symbols accepted by symbol-file: defvar and defface? >> >> No it does not exists. >> >> The reason why the compilation unit concept was introduced is to have >> the GC capable of unloading the eln when possible, this mechanism is >> only related to functions that are indeed memory mapped from the loaded >> shared libraries. Variables etc are just regular variables (tipically >> defined at eln load time) so they didn't required any new mechanism. >> >> > If not, then the only way to produce the same information for them >> > would be to generate the base name of the .eln file with >> > comp-el-to-eln-rel-filename, and then look for that file along >> > native-comp-eln-load-path, right? >> >> Yes I think so. > > Andrea and Alan, please review and test the version of symbol-file > below that I intend to install soon. TIA. > > (defun locate-eln-file (eln-file) > "Locate a natively-compiled ELN-FILE by searching its load path. > This function looks in directories named by `native-comp-eln-load-path'." > (or (locate-file-internal (concat comp-native-version-dir "/" eln-file) > native-comp-eln-load-path) > (locate-file-internal > ;; Preloaded *.eln files live in the preloaded/ subdirectory of > ;; the last entry in `native-comp-eln-load-path'. > (concat comp-native-version-dir "/preloaded/" eln-file) > (last native-comp-eln-load-path)))) > > (defun symbol-file (symbol &optional type native-p) > "Return the name of the file that defined SYMBOL. > The value is normally an absolute file name. It can also be nil, > if the definition is not associated with any file. If SYMBOL > specifies an autoloaded function, the value can be a relative > file name without extension. > > If TYPE is nil, then any kind of definition is acceptable. If > TYPE is `defun', `defvar', or `defface', that specifies function > definition, variable definition, or face definition only. > Otherwise TYPE is assumed to be a symbol property. > > If NATIVE-P is nil, and SYMBOL was loaded from a .eln file, this > function will return the absolute file name of that .eln file, > if found. > > This function only works for symbols defined in Lisp files. For > symbols that are defined in C files, use `help-C-file-name' > instead." > (if (and (or (null type) (eq type 'defun)) > (symbolp symbol) > (autoloadp (symbol-function symbol))) > (nth 1 (symbol-function symbol)) > (if (and native-p (or (null type) (eq type 'defun)) > (symbolp symbol) > (subr-native-elisp-p (symbol-function symbol))) > ;; native-comp-unit-file returns unnormalized file names. > (expand-file-name (native-comp-unit-file (subr-native-comp-unit > (symbol-function symbol)))) > (let ((elc-file > (catch 'found > (pcase-dolist (`(,file . ,elems) load-history) > (when (if type > (if (eq type 'defvar) > ;; Variables are present just as their > ;; names. > (member symbol elems) > ;; Many other types are represented as > ;; (TYPE . NAME). > (or (member (cons type symbol) elems) > (memq > symbol > (alist-get type > (alist-get 'define-symbol-props > elems))))) > ;; We accept all types, so look for variable def > ;; and then for any other kind. > (or (member symbol elems) > (let ((match (rassq symbol elems))) > (and match > (not (eq 'require (car match))))))) > (throw 'found file)))))) > ;; If they asked for the .eln file, try to find it. > (or (and elc-file > native-p > (let* ((sans-ext (file-name-sans-extension elc-file)) > (el-file > (and (fboundp 'zlib-available-p) > (zlib-available-p) > (concat sans-ext ".el.gz"))) > (el-file-backup (concat sans-ext ".el"))) > (or (and el-file (file-exists-p el-file)) > (and (file-exists-p el-file-backup) > (setq el-file el-file-backup)) > (setq el-file nil)) > (if (stringp el-file) > (locate-eln-file > (comp-el-to-eln-rel-filename el-file))))) > elc-file))))) Hi Eli, I think this has some overlap with the code we have in 'maybe_swap_for_eln', but it does not look trivial to decouple it, so I'm not sure is it worth the pain. Other than that only note I've is that (in 'maybe_swap_for_eln1') we do reject the .eln file if it's younger than the corresponding .elc one. I think we should mimic this as well here no? Otherwise LGTM. Thanks Andrea