bug#34322: reproducibility: absolute file name in tramp.elc

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Glenn Morris-3
Package: emacs
Version: 26.1.91
Severity: minor

Perhaps the same issue as https://debbugs.gnu.org/34321 .
The definition of tramp-lookup-syntax in tramp.elc contains the absolute
file name of the build directory, making the file non-reproducible.
Eg in the 26.1.91 pretest tarfile, it contains
"/home/nico/work/emacs-26/lisp/net/tramp-compat.elc"



Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Michael Albinus
Glenn Morris <[hidden email]> writes:

> Perhaps the same issue as https://debbugs.gnu.org/34321 .
> The definition of tramp-lookup-syntax in tramp.elc contains the absolute
> file name of the build directory, making the file non-reproducible.
> Eg in the 26.1.91 pretest tarfile, it contains
> "/home/nico/work/emacs-26/lisp/net/tramp-compat.elc"

Don't know how to fix it. For the records, in the emacs-26 branch,
tramp.elc contains

--8<---------------cut here---------------start------------->8---
(defalias 'tramp-lookup-syntax #[257 "\301 \236A\206\f\302\303\"\207" [tramp-syntax #[0 "\301\267\202\n\302\207\303\207\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 8)) default separate] 2 ("/usr/local/src/emacs-26/lisp/net/tramp-compat.elc" . 7408)] error "Wrong `tramp-syntax' %s"] 4 (#$ . 25891)])
--8<---------------cut here---------------end--------------->8---

OTOH, in the Tramp git repository, branch tramp-2-3-stable, tramp.elc contains

--8<---------------cut here---------------start------------->8---
(defalias 'tramp-lookup-syntax #[257 "\301\267\202\302\202\303\202\236A\206\304\305\"\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10)) default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
--8<---------------cut here---------------end--------------->8---

I have no idea where the absolute file name in the former comes
from. Both repositories use the same Emacs 26.1.91 binary for the build.

Best regards, Michael.



Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Eli Zaretskii
In reply to this post by Glenn Morris-3
> From: Glenn Morris <[hidden email]>
> Date: Mon, 04 Feb 2019 17:58:50 -0500
>
> Package: emacs
> Version: 26.1.91
> Severity: minor
>
> Perhaps the same issue as https://debbugs.gnu.org/34321 .
> The definition of tramp-lookup-syntax in tramp.elc contains the absolute
> file name of the build directory, making the file non-reproducible.
> Eg in the 26.1.91 pretest tarfile, it contains
> "/home/nico/work/emacs-26/lisp/net/tramp-compat.elc"

It seems to be a reference to the place in tramp-compat.elc where
tramp-compat-tramp-syntax is defined.  Maybe some byte-compiler guru
could explain or guess when does the byte compiler use such
references.  Stefan, any ideas?



Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Eli Zaretskii
In reply to this post by Michael Albinus
> From: Michael Albinus <[hidden email]>
> Date: Tue, 05 Feb 2019 10:00:15 +0100
> Cc: [hidden email]
>
> Don't know how to fix it. For the records, in the emacs-26 branch,
> tramp.elc contains
>
> --8<---------------cut here---------------start------------->8---
> (defalias 'tramp-lookup-syntax #[257 "\301 \236A\206\f\302\303\"\207" [tramp-syntax #[0 "\301\267\202\n\302\207\303\207\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 8)) default separate] 2 ("/usr/local/src/emacs-26/lisp/net/tramp-compat.elc" . 7408)] error "Wrong `tramp-syntax' %s"] 4 (#$ . 25891)])
> --8<---------------cut here---------------end--------------->8---
>
> OTOH, in the Tramp git repository, branch tramp-2-3-stable, tramp.elc contains
>
> --8<---------------cut here---------------start------------->8---
> (defalias 'tramp-lookup-syntax #[257 "\301\267\202 \302\202 \303\202 \236A\206 \304\305\"\207" [tramp-syntax #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10)) default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
> --8<---------------cut here---------------end--------------->8---
>
> I have no idea where the absolute file name in the former comes
> from.

I tried to explain what it means in another message.

> Both repositories use the same Emacs 26.1.91 binary for the build.

I think whether there is or isn't such a reference depends on whether
tramp-compat.elc exists when you byte-compile tramp.c.  Try removing
the former or renaming it, and you get the contents you have in the
second excerpt.  So perhaps whether the reference exists or not
depends on the order of the compilation, and maybe also on how many
compilation jobs in parallel are run when boostrapping Emacs.



Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Stefan Monnier
>> --8<---------------cut here---------------start------------->8---
>> (defalias 'tramp-lookup-syntax #[257 "\301 \236A\206\f\302\303\"\207"
>> [tramp-syntax #[0 "\301\267\202\n\302\207\303\207\207" [tramp-syntax
>> #s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 0.8125
>> purecopy t data (ftp 6 sep 8)) default separate]
>> 2 ("/usr/local/src/emacs-26/lisp/net/tramp-compat.elc" . 7408)] error
>> "Wrong `tramp-syntax' %s"] 4 (#$ . 25891)])
>> --8<---------------cut here---------------end--------------->8---

Hmm... looks like a bug in the implementation of defsubst: it works by
replacing references to tramp-compat-tramp-syntax with a copy of the
function's byte-code (this is the #[0 ...] object above, which includes
the source file name info), and later on those copied bytecode objects
are normally spliced into the surrounding bytecode (at which point the
extra source info is dropped), but here it seems like it hasn't been
spliced as it should.

>> --8<---------------cut here---------------start------------->8---
>> (defalias 'tramp-lookup-syntax #[257 "\301\267\202 \302\202 \303\202
>> \236A\206 \304\305\"\207" [tramp-syntax #s(hash-table size 2 test eq
>> rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10))
>> default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
>> --8<---------------cut here---------------end--------------->8---

Here you can see that there is no nested bytecode object (i.e. no
#[...] with the main #[...]) so the call has been correctly inlined.

> I think whether there is or isn't such a reference depends on whether
> tramp-compat.elc exists when you byte-compile tramp.c.  Try removing

I don't think we've changed anything significant in the implementation
of defsubst so indeed it's likely triggered by something like the order
of compilation.


        Stefan



Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Michael Albinus
Stefan Monnier <[hidden email]> writes:

>>> --8<---------------cut here---------------start------------->8---
>>> (defalias 'tramp-lookup-syntax #[257 "\301\267\202 \302\202 \303\202
>>> \236A\206 \304\305\"\207" [tramp-syntax #s(hash-table size 2 test eq
>>> rehash-size 1.5 rehash-threshold 0.8125 purecopy t data (ftp 6 sep 10))
>>> default separate error "Wrong `tramp-syntax' %s"] 4 (#$ . 25800)])
>>> --8<---------------cut here---------------end--------------->8---
>
> Here you can see that there is no nested bytecode object (i.e. no
> #[...] with the main #[...]) so the call has been correctly inlined.

Given, that the absolute file name is not needed in the bytecode, I'm
wondering why we insert it there. Couldn't we live without?

>         Stefan

Best regards, Michael.



Reply | Threaded
Open this post in threaded view
|

bug#34322: reproducibility: absolute file name in tramp.elc

Stefan Monnier
>> Here you can see that there is no nested bytecode object (i.e. no
>> #[...] with the main #[...]) so the call has been correctly inlined.
> Given, that the absolute file name is not needed in the bytecode,

It's present in the in-memory bytecode object so that `C-h f` can jump
to the source upon demand, so it is needed.

> I'm wondering why we insert it there.

It's because we just insert the bytecode object wholesale (not a copy of
the object), so it comes with all its fields.

> Couldn't we live without?

We'd have to make a copy of the bytecode object, skipping the
source-code reference.

But really, this is actually a side-problem: the inlined bytecode is not
spliced the way it should, so the inlining optimization is basically
missing.  Such a half-assed inlining gives you all the downsides of
inlining without its upsides.  Once we fix that, the reproducibility
problem will also be fixed.


        Stefan