From: Paul Eggert <eggert@cs.ucla.edu>
To: Daniel Colascione <dancol@dancol.org>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in
Date: Thu, 11 Apr 2019 20:45:58 -0700 [thread overview]
Message-ID: <597d5c5a-f8c1-3b69-006d-6e3da4b1124d@cs.ucla.edu> (raw)
In-Reply-To: <e3d6d45ae527eff283e7cf9aa64522c7.squirrel@dancol.org>
Daniel Colascione wrote:
>> what exactly is the failure scenario here? I'm not seeing any
>> failure scenarios for the current approach that can't also be failure
>> scenarios for the previous approach
>
> It's likely that the linker to lay out objects in a section identically in
> two different builds when the only difference between the builds is the
> content of an array.
Sure, but it's even more likely for linkers to lay out objects in a section
identically in two different builds when there is no difference whatsoever
between the inputs to the builds. So I'm still not seeing the failure scenario
for the current approach that wouldn't also be a failure scenario for the
previous (temacs.in) approach.
> If we're worried about the array being folded into
> the code, we can make it volatile.
That wouldn't be enough; we'd need the volatile accesses to memory under the
program's control being tricky enough (they aren't now) so that the compiler
couldn't optimize them away or reorder the array or whatever. Admittedly this is
getting a little theoretical (but then this particular point is pretty
theoretical anyway :-).
> If someone changes a linker flag that
> changes object ordering, temacs.in will change.
Right, but that can also affect temacs in the previous approach; that is,
temacs.in might be linked with different flags than temacs is. Or the linker
might be upgraded between the time that temacs.in is built, and the time that
temacs is built. So these failure scenarios apply to the previous approach too.
If we rely on a fingerprint we have to give up on the idea of an ironclad
guarantee that if the fingerprint matches, Emacs is compatible. We have to
settle for just a high-enough probability in practice.
We could document ways in which the low-probability events can occur (hash
collision, linker change that breaks reproducible builds, etc.). Or we could
change the pdumper so that it doesn't rely on a fingerprint: instead, Emacs
could record a complete description of what it's assuming in the dump file, and
check this description when it reads the dump back in. However, that'd be some
work and is almost surely overkill.
next prev parent reply other threads:[~2019-04-12 3:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190409224339.20116.87667@vcs0.savannah.gnu.org>
[not found] ` <20190409224342.0DA1F20E54@vcs0.savannah.gnu.org>
2019-04-10 18:53 ` [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in Daniel Colascione
2019-04-10 19:31 ` Paul Eggert
2019-04-10 19:42 ` Daniel Colascione
2019-04-10 20:43 ` Paul Eggert
2019-04-10 20:56 ` Daniel Colascione
2019-04-11 3:31 ` Paul Eggert
2019-04-11 22:24 ` Daniel Colascione
2019-04-12 3:45 ` Paul Eggert [this message]
2019-04-12 4:20 ` Daniel Colascione
2019-04-13 6:52 ` Eli Zaretskii
2019-04-14 3:40 ` Stefan Monnier
2019-04-14 3:43 ` Daniel Colascione
2019-04-14 4:08 ` Stefan Monnier
2019-04-14 14:03 ` Eli Zaretskii
2019-04-14 14:55 ` Stefan Monnier
2019-04-14 15:47 ` dancol
2019-04-14 17:30 ` Stefan Monnier
2019-04-14 17:44 ` Eli Zaretskii
2019-04-15 0:19 ` Paul Eggert
2019-04-11 19:35 ` Stefan Monnier
2019-04-11 22:15 ` Daniel Colascione
2019-04-11 23:37 ` Stefan Monnier
[not found] ` <20190409224341.BED1520E43@vcs0.savannah.gnu.org>
2019-04-10 19:00 ` [Emacs-diffs] master e44ff2d 2/3: Remove assumption of uint64_t etc. in portable code Daniel Colascione
2019-04-10 19:51 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=597d5c5a-f8c1-3b69-006d-6e3da4b1124d@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=dancol@dancol.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.