bug#50666: 28.0.50; Fix native compilation on Cygwin

[Eli Zaretskii <eliz@gnu.org>]

> From: Achim Gratz <Stromeko@nexgo.de>
> Date: Thu, 23 Sep 2021 19:49:05 +0200
> 
> Eli Zaretskii writes:
> >> We still need to do something for 64-bit Cygwin.  Even though address collisions 
> >> are unlikely they could still happen theoretically.  But there might be a much 
> >> easier solution that doesn't necessarily require rebasing.  For example, Achim 
> >> mentioned earlier the possibility of marking the eln as ASLR w/ high-entropy and
> >> large address aware.
> >
> > Isn't that the default of the 64-bit GNU ld on Windows?  Or does
> > Cygwin configure Binutils differently from MinGW?
> 
> No, I've had to remove that default since obviously it doesn't work on
> Cygwin.

You mean, ASLR doesn't work with Cygwin because it must use the same
address in the forked process?  But then why did Ken say that ASLR and
High Entropy could solve the problem with the *.eln files -- isn't
that the same problem?

> > If not, we can use native-comp-driver-options, by giving it a non-nil
> > value for Cygwin, to force this.
> 
> All that would be needed, on 64bit at least, is a tiny bit more control
> over how ASLR works, but there isn't even proper documentation about
> what it actually does (that I can find anyway).  M$ must have solved
> that problem for WSL1, but whatever it was, it didn't make it to the NT
> subsystem.

Sorry, I don't understand.  My suggestion was, if you need to make the
*.eln files be marked as ASLR with High Entropy, to use a variable we
have for this purpose, it will force the linker to produce *.eln files
with these bits set in the PE+ header.  What other control do you need
for your purposes, or what am I missing?