[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pdumping "into" the executable
From: |
dancol |
Subject: |
Re: pdumping "into" the executable |
Date: |
Mon, 26 Feb 2018 15:34:41 -0800 |
User-agent: |
SquirrelMail/1.4.23 [SVN] |
> 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.
The built-in symbols are in one big contiguous array. That's why the
scheme works.
- pdumping "into" the executable, Stefan Monnier, 2018/02/26
- Re: pdumping "into" the executable, Daniel Colascione, 2018/02/26
- Re: pdumping "into" the executable, Tom Tromey, 2018/02/26
- Re: pdumping "into" the executable, dancol, 2018/02/26
- Re: pdumping "into" the executable, Paul Eggert, 2018/02/26
- Re: pdumping "into" the executable, Daniel Colascione, 2018/02/26
- Re: pdumping "into" the executable, Paul Eggert, 2018/02/26
- Re: pdumping "into" the executable,
dancol <=
- Re: pdumping "into" the executable, dancol, 2018/02/26
- RE: pdumping "into" the executable, Drew Adams, 2018/02/26
- RE: pdumping "into" the executable, dancol, 2018/02/26
- Re: pdumping "into" the executable, John Wiegley, 2018/02/27
- Re: pdumping "into" the executable, Dmitry Gutov, 2018/02/27
- Re: pdumping "into" the executable, Stefan Monnier, 2018/02/27
- Re: pdumping "into" the executable, John Wiegley, 2018/02/27
- Re: pdumping "into" the executable, Clément Pit-Claudel, 2018/02/26
- Re: pdumping "into" the executable, Daniel Colascione, 2018/02/26