From: "Daniel Colascione" <dancol@dancol.org>
To: "Paul Eggert" <eggert@cs.ucla.edu>
Cc: Daniel Colascione <dancol@dancol.org>, emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in
Date: Wed, 10 Apr 2019 13:56:06 -0700 [thread overview]
Message-ID: <0c98c320ec76444fb5af1971d8f99360.squirrel@dancol.org> (raw)
In-Reply-To: <ce361f3c-e993-cf87-9229-2932ad075af5@cs.ucla.edu>
> On 4/10/19 12:42 PM, Daniel Colascione wrote:
>> PIE and shared libraries are irrelevant. The whole point of pdumper is
>> to
>> be invariant across different PIE and DSO configurations.
>
> Yes, and that's part of the point. Because the pdumper doesn't care how
> 'write' is implemented so long as it's done correctly, the fingerprint
> doesn't need to include a checksum of the implementation of 'write'.
> There's a good chunk of the Emacs executable that is in the same
> category as 'write' - that is, the chunk doesn't matter for the purposes
> of the fingerprint. Whether we checksum the irrelevant chunk is a
> pragmatic/efficiency issue; it's not needed for correctness.
>
> With this in mind, checksumming the .o files ought to be enough to
> generate a fingerprint good enough for the intended purpose of the
> checksum. The checksum won't capture how 'write' is implemented, nor
> will it capture detailed decisions about how the linker lays out Emacs's
> low-level objects, but that's OK: the pdumper doesn't care about those
> things so long as they're done correctly.
No: that's simply wrong. pdumper *does* care about the low-level layout of
objects within Emacs. We have dump-to-emacs relocations based on offsets
from a known symbol within Emacs. The linker deciding to lay out objects
within sections in a different order will break the dump. We don't care
how the linker lays out the object so long as it's the same in the binary
that makes a dump and the binary that loads the dump. Your change makes it
possible for incompatible Emacs binaries to have the same fingerprint.
>> The temacs.in mechanism
>> covers all current and *and unknown future* binary layout modifications.
>> It breaks only if linker symbol arrangement depends on randomness or on
>> the precise content of the fingerprint array, and both of these
>> possibilities are unlikely.
>
> The mechanism could also "break" with whole-program optimization that
> inlines the fingerprint array, or with other plausible future changes to
> linkers as they get smarter.
The optimization you've described doesn't matter: as long as changing the
*value* of the fingerprint array (not its length!) preserves Emacs *object
layout* change in Emacs, we're good.
> But none of this should matter, as any such
> "breakage" should be irrelevant to the pdumper.
It's quite relevant. Please either revert the temacs.in removal patch or
implement the inline fingerprint stamping I described. The way you've left
it is broken.
next prev parent reply other threads:[~2019-04-10 20:56 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 [this message]
2019-04-11 3:31 ` Paul Eggert
2019-04-11 22:24 ` Daniel Colascione
2019-04-12 3:45 ` Paul Eggert
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=0c98c320ec76444fb5af1971d8f99360.squirrel@dancol.org \
--to=dancol@dancol.org \
--cc=eggert@cs.ucla.edu \
--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.