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 11:01:04 +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> 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="32501"; 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 12:03:20 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 1l6WzI-0008N2-2C for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Feb 2021 12:03:20 +0100 Original-Received: from localhost ([::1]:40728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6WzH-0004IL-54 for ged-emacs-devel@m.gmane-mx.org; Mon, 01 Feb 2021 06:03:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6WxG-0003Ng-IT for emacs-devel@gnu.org; Mon, 01 Feb 2021 06:01:15 -0500 Original-Received: from mab.sdf.org ([205.166.94.33]:49866 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 1l6WxE-00041q-0r; Mon, 01 Feb 2021 06:01:14 -0500 Original-Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1l6Wx6-0004Ut-Hl; Mon, 01 Feb 2021 11:01:04 +0000 In-Reply-To: <83sg6h6s6d.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 31 Jan 2021 17:29:30 +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=ham 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:263682 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: phillip.lord@russet.org.uk, emacs-devel@gnu.org >> Date: Sat, 30 Jan 2021 20:17:58 +0000 >> >> >> native-lisp/28.0.50-x86_64-w64-mingw32-HASH1/titdic-cnv-HASH2-HASH3.eln >> >> >> >> - HASH1 disambiguate triplet, Emacs configuration, version etc. >> > >> > But that information is already present in the text before: >> > 28.0.50-x86_64-w64-mingw32. What else is missing that we need a hash? >> >> I left the text before as indicative and human readable but >> unfortunatelly that's not complete. >> >> The list of all primitive functions contribute to the eln linking >> mechanism we use and is accounted in this hash. Also we can trigger the >> generation of a new hash each time we deploy an eln ABI breaking change. > > Sorry, I don't follow. You said HASH1 disambiguates the triplet, and > that is already present in the name. Please elaborate on the other > factors that affect HASH1, as what you said (primitives that > contribute? eln ABI breaking changes?) isn't enough for me to > understand what information they record. Sure, 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. > 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?). Regards Andrea