[ld] 2.36 PE flags changes (PR19011, commit 514b4e19)

[Jan Beulich]

On 28.02.2021 13:22, ASSI wrote:
> 
> This change is fundamentally incompatible with how Cygwin operates (and
> also MSys2 since they're using the same code base, although they don't
> seem to have that fully realized yet).  So I'll have to patch it out for
> Cygwin (and likely MingW64 the cross compilation toolchain to be safe).
> 
> I am wondering how this change made it into the code base without a
> configure option.  Also, the way it was announced is somewhat misleading
> since it also affects executables, not just DLL (I wasn't even aware
> that ASLR would affect executables, but it does -- if anybody knows
> where that is documented, please let me know).  In other words, you can
> create failures by simply compiling to an a.out file since that will now
> have both ASLR and NX switched on for i686 and additionally high entropy
> for x86_64 as this excerpt from running a bog standard configure test
> for fork shows:

As reported previously, that change has caused me headache too,
entirely outside of Cygwin or alike. However, having looked at
the change in some detail, I'm not sure I see the ASLR aspect here,
since ...

> --8<---------------cut here---------------start------------->8---
> checking for working fork...       1 [main] conftest 7615 D:\Freeware\CygProShare\cygpkgs\mosh\mosh.x86\build\conftest.exe: *** fatal error in forked process - fork: can't reserve 
> memory for parent stack 0x1400000 - 0x1600000, (child has 0x840000 - 0xA40000), Win32 error 487
>   74330 [main] conftest 7615 cygwin_exception::open_stackdumpfile: Dumping stack trace to conftest.exe.stackdump

... 0x1400000 doesn't look like a randomized (image base?) address,
but a link-time one. So I wonder what specific "flags" changes you
are talking about. Of course I know nothing about Cygwin's
internal workings, yet a first guess would be that it doesn't deal
properly with the case where said range is already occupied (by
the executable image in this case, as it would seem)? If that was
the case, then the binutils change would merely have uncovered a
shortcoming ...

Irrespective I do agree with what I imply from your posting - the
change, despite its good intentions, didn't care enough about
compatibility with existing use cases.

Jan