From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: akrl--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [feature/native-comp] breakage on build Date: Mon, 01 Feb 2021 16:20:17 +0000 Message-ID: References: <87lfca7lsb.fsf@russet.org.uk> <463a837ca8ddbf7533c403350d75125d@russet.org.uk> <39105f71034e0902a749994dda9c4704@russet.org.uk> <83mtwq8kf3.fsf@gnu.org> <83k0ru8jnx.fsf@gnu.org> <83im7e8icf.fsf@gnu.org> <838s8a8adr.fsf@gnu.org> <83sg6h6s6d.fsf@gnu.org> <8335yf7qtf.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="11601"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 01 17:26:34 2021 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 1l6c25-0002qN-QI for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Feb 2021 17:26:33 +0100 Original-Received: from localhost ([::1]:37976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6c24-0002nd-QT for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Feb 2021 11:26:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49428) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6bwN-0006mW-6I for emacs-devel@gnu.org; Mon, 01 Feb 2021 11:20:43 -0500 Original-Received: from mab.sdf.org ([205.166.94.33]:50896 helo=ma.sdf.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6bw6-0005dX-3X; Mon, 01 Feb 2021 11:20:38 -0500 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1l6bw1-0000Pk-2V; Mon, 01 Feb 2021 16:20:17 +0000 In-Reply-To: <8335yf7qtf.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 01 Feb 2021 17:25:48 +0200") Received-SPF: pass client-ip=205.166.94.33; envelope-from=akrl@sdf.org; helo=ma.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_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:263686 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: phillip.lord@russet.org.uk, emacs-devel@gnu.org >> Date: Mon, 01 Feb 2021 11:01:04 +0000 >> >> each .eln while executing must indeed call into Emacs C code. Call >> happens through function pointers, say we must call Fmessage, something >> like this will be rendered into the eln: >> >> freloc_link_table->Fmessage (...) >> >> 'freloc_link_table' is a pointer statically allocated within the eln >> object, it gets set while loading to point to the right data structure >> in memory. This data structure is a C structure holding all function >> pointers to all Emacs primitive functions. >> >> For this reason we must be sure that the definition of >> 'freloc_link_table' use while compiling the eln matches the one offered >> by the Emacs loading the eln file. >> >> This is the main reason eln are not portable between different Emacs >> configurations. >> >> HASH1 has the duty to disambiguates this and everything else that could >> reflect into an incompatibility of the eln (`system-configuration` >> `emacs-version`). >> >> As from time to time we can refine mechanisms like the load mechanism or >> anything else and consequentially generating another incompatibility the >> macro ABI_VERSION also contribute to HASH1. I bump a new number there >> each time I realize I'm changing something that introduce and >> incompatibility. >> >> To summarize eln was never designed for compatibility across versions or >> configurations and HASH1 is made to guard against that. > > OK, thanks. I understand the reasons now. However, I'm not sure we > should encode all this information in the .eln file's name. For > starters, some of those reasons are also true for *.elc files, right? > For example, suppose that a primitive that the .el file calls changed > its signature in backward-incompatible ways -- the .el files which > call it need to be recompiled, or else they will fail, either silently > or noisily. Right? But we don't encode those details in the names of > the *.elc files, do we? Why should the *.eln files be different? I think with eln the situation is considerably more sentitive than the elc one in this respect. The reason is that we (on purpose) skip Ffuncall to call directly into C code, as a consequence an incompatibility will most certainly lead to a crash and not a runtime error. > Next, why not encode this information in some data in the *.eln files, > and have the code which loads the *.eln files check the compatibility > and reject the load if they don't match? Why encode this information > in the file's name? We can imagine two alternative scenarios: 1- We merge HASH1 and HASH3 - In this case everything will work as of now but certain operations will become more difficult, the typical example is manually removing all the eln left by an old Emacs configuration that is not anymore in use (me and others do this quite often). 2- We move HASH1 into the eln as metadata. - The limitation of 1 persists - To check that each eln is loadable one has: to 'dlopen' it, read the metadata ('dlsym'), verify and in case reject. This is certainly way more expansive than directly searching for a given filename and might impact negatively startup time, especially on certain OSes where opening files is an expensive operation. - We'd have name clashes for different eln coming from different Emacs configurations/versions. >> > And in any case, if the triplet is in HASH1, why not remove its >> > human-readable representation and save a few bytes? >> >> At the time was thought to be convinient to have the triplet also as >> human readable. Indeed no problem from my side on removing it if this >> is problematic (wasn't aware of this Windows limitation). >> >> That said I think the main cure for this Windows file length issue is to >> diet down the hash length to something more reasonable (16 or 8 >> characters?). > > I think we should do both. The chances that the same cache directory > will be used for different architectures is pretty low anyway. Okay. Shall we pick a length? 8 characters is probably more than okay but we can go for 16 if we prefer to stay on the safe side. Thanks Andrea