GNU bug report logs - #79684
[PATCH] Check native comp ABI version

Previous Next

To reply to this bug, email your comments to 79684 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Andrea Corallo <acorallo <at> gnu.org>
Subject: [PATCH] Check native comp ABI version
Date: Thu, 23 Oct 2025 14:48:19 +0200

[Message part 1 (text/plain, inline)]

Tags: patch

Native-comp currenty does not explicitly check that the ABI version when
an .eln was produced is the same as the ABI version when an .eln is
loaded. It relies on putting a substring of an MD5 sum in the file name
instead (see hash_native_abi).

This proved insufficient in a case I had here, which is why I added an
explicit check to my Emacs.

Andrea is in CC.

[0001-Check-native-comp-ABI-version.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <acorallo <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: [PATCH] Check native comp ABI version
Date: Thu, 23 Oct 2025 09:53:16 -0400

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Tags: patch
>
> Native-comp currenty does not explicitly check that the ABI version when
> an .eln was produced is the same as the ABI version when an .eln is
> loaded. It relies on putting a substring of an MD5 sum in the file name
> instead (see hash_native_abi).
>
> This proved insufficient in a case I had here, which is why I added an
> explicit check to my Emacs.
>
> Andrea is in CC.

Hi Gerd,

could you describe exactly which scenario proved the current setup to be
insufficient?  AFAIR we use the the ABI version to form the filename to
look for no?

Thanks!

  Andrea

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Andrea Corallo <acorallo <at> gnu.org>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: [PATCH] Check native comp ABI version
Date: Thu, 23 Oct 2025 16:23:37 +0200

Andrea Corallo <acorallo <at> gnu.org> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Tags: patch
>>
>> Native-comp currenty does not explicitly check that the ABI version when
>> an .eln was produced is the same as the ABI version when an .eln is
>> loaded. It relies on putting a substring of an MD5 sum in the file name
>> instead (see hash_native_abi).
>>
>> This proved insufficient in a case I had here, which is why I added an
>> explicit check to my Emacs.
>>
>> Andrea is in CC.
>
> Hi Gerd,
>
> could you describe exactly which scenario proved the current setup to be
> insufficient?  AFAIR we use the the ABI version to form the filename to
> look for no?

Not 100% exactly I'm afraid, but let me try. It went something like
this:

I have a "very" old todo item that I'm working on and off when I feel
like it. This is about the roots igc is using to scan the Lisp_Objects
in, mainly, the d_relocs vectors in the data segments of .eln files.
They have to be scanned because MPS is a copying collector and objects
can move in memory. These roots are in sum pretty large, in my case,
with my init file and so on, they amount to ca. 1.5 MB, which increases
GC latency because all roots must be scanned before anything can be
copied during GC and so on.

These d_reloc vectors are filled when an .eln is loaded by using the
Lisp reader to produce a vector from a string the text segment. The
contents of this vector are then copied to the d_reloca arrays in the
data segment.

The idea I'm trying out, with very slow progress, is to change this to
use an additional indirection in the native code. I'm not copying the
vector's contents to the data segment d_reloc, but store a pointer to
the "contents" member of the vector. That is, where the code currently
does something akin to

  static Lisp_Object d_reloc[42];
  ...
  Lisp_Object x = d_reloc[17];

it then does the moral equivalent of 

  static Lisp_Object **d_reloc;
  ...
  Lisp_Object x = (*d_reloc)[17];

IOW, I'm trying to trade less GC latency for an additional indirection,
and see which one I like better.
  
For all that I changed ABI_VERSION. Then I built, and it loaded an .eln
that had the wrong version, which took me a looong time to make sense
of. That's basically the background of the whole story (plus that there
seems to also be something weird in the build system that sometimes
leads to loading stuff from an installation in ~/.local, but that's a
different story.)

Anyway, when I checked this

comp.c:
  802 void
  803 hash_native_abi (void)
  804 {
  805   /* Check runs once.  */
  806   eassert (NILP (Vcomp_abi_hash));
  807 
  808   Vcomp_abi_hash =
  809     comp_hash_string (
  810       concat3 (build_string (STR (ABI_VERSION)),
  811                concat3 (Vemacs_version, Vsystem_configuration,
  812                         Vsystem_configuration_options),
  813                Fmapconcat (intern_c_string ("comp--subr-signature"),
  814                            Vcomp_subr_list, build_string (""))));
  815 

I had my doubts that each change in only the ABI_VERSION for example
lands in the result of that function. MD5 and substring, and so on. The
patch caught that case, FWIW.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.