unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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: Wed, 10 Apr 2019 13:43:15 -0700	[thread overview]
Message-ID: <ce361f3c-e993-cf87-9229-2932ad075af5@cs.ucla.edu> (raw)
In-Reply-To: <7bd7a4577abcebd089c7aecc253718f2.squirrel@dancol.org>

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.

> 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. But none of this should matter, as any such
"breakage" should be irrelevant to the pdumper.




  reply	other threads:[~2019-04-10 20:43 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 [this message]
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
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce361f3c-e993-cf87-9229-2932ad075af5@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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).