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: Tue, 02 Aug 2022 08:43:53 +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="7300"; 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 Tue Aug 02 11:08:23 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 1oInt1-0001hN-PC for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Aug 2022 11:08:23 +0200 Original-Received: from localhost ([::1]:41338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oInt0-0003yB-Mn for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Aug 2022 05:08:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45962) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oInVO-0008Pd-4F for emacs-devel@gnu.org; Tue, 02 Aug 2022 04:43:58 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:59109) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oInVL-0002Tm-Cf; Tue, 02 Aug 2022 04:43:57 -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 2728hqWF005628 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 2 Aug 2022 08:43:53 GMT In-Reply-To: (Andrea Corallo's message of "Mon, 01 Aug 2022 09:23:05 +0000") 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:292973 Archived-At: Andrea Corallo writes: > 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? I do realize now this is probably not a real case as: if (in 'maybe_swap_for_eln1') we reject the eln while loading because older than the elc we give up entirely on loading native code, even if might be available in another directory down in `native-comp-eln-load-path'. So your code should be just fine in this respect. Thanks Andrea