Subject: Re: bug#41242: Port feature/native-comp to Windows

From: Andrea Corallo <[email-masked]>
Date: Sat, 23 May 2020 16:00:52 +0000

Nicolas Bértolo <[email-masked]> writes:

>> I don't think would fly: You are not garanteed to be able to obtain
> the
>> same mmaped address anyway and we cannot go for a solution that
> does not
>> support ASLR.  In general to be portable it cannot rely on
> assumptions
>> or low level tricks.  I think these are (at least part of) the
> reasons
>> why we moved away from unexec.
>
> AFAIU ASLR is disabled already, at least in Windows.

The fact that is now disabled does not imply that we want to prevent us
from using it for the future, that said AFAIU given the personality of
my running Emacs is zeroed (i'm on GNU/Linux) it is running with ASLR
enabled.  See also 'maybe_disable_address_randomization'.

>> Is not that simple, loading eln is mutating the environment with
> side
>> effects, function definition is just a part of that.
>
> I know, but linking against a static .eln would just make the symbols
> available,
> not anything else. The mutation of the environment would happen when
> loading
> the dump.

Is more complex because we can have in the eln code that at top level
relies on functions as:

(defun foo ()
  ..)

(some code that depends on the definition of foo)

(defun foo ()
  ..)

So function definition and other top level executon is mixed.  I think
this could be worked around but is tricky.

>> Even more important we must support subsequent dumps.
>
> You are right. I hadn't considered this.

Yeah I think this the real no go.

  Andrea

-- 
[email-masked]