Re: pdumping "into" the executable

[Paul Eggert]

On 02/26/2018 02:22 PM, Daniel Colascione wrote:
> On 12/31/1969 04:00 PM, Paul Eggert wrote:
> > On 02/26/2018 01:18 PM, address@hidden wrote:
> > > > Or, just turn the dump to a C file, then compile it
> > > > and do a second link.  Aside from (maybe hypothetical) C compiler
> > > > limits, that would be very portable.
> > > But not redumpable.
> >
> > Why couldn't it be redumpable? All that the user should need is a C 
> > compiler. That's not unreasonable.
>
> I thought we had this argument back when we were talking about 
> modules. I think it's unacceptable to require a C compiler and the 
> presence of Emacs unlinked objects for the proper operation of an 
> end-user feature.

Although using a dumped Emacs is an end-user feature, dumping and 
redumping are not. Dumping and/or redumping are techniques used to build 
Emacs, and in practice they should be part of a software build system; 
for such a thing it's reasonable to assume a C compiler.

We already assume a C compiler (or equivalent) when building modules; we 
don't assume a C compiler only when people are using the modules. 
Dumping is similar.

> > > Besides, the problem with a second link is that it might change the
> > > relative positions of symbols within Emac
> >
> > How could that be a problem? Symbols known to C code are known by 
> > their fixed offsets and the second link wouldn't change these 
> > offsets, and symbols not known to C code need to be reallocated 
> > anyway during loading.
>
> The linker is what determines into-translation-unit offsets, not the 
> compiler. The offsets are patched in at link time. There's no 
> particular requirement to perform the link the same way every time.

For Lisp symbols visible to C, Emacs master currently determines symbol 
offsets at C-compile-time, not at link time. Does pdumper change this? 
If so, how and why does it change this? And if not, then I don't see the 
problem.