Re: [Emacs-diffs] master d826037 3/3: Remove the need for temacs.in

[Daniel Colascione]

> 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.