Re: freshly built wx86cl64.exe crashes on start

Unfortunately yes in low memory for now. But as I pointed earlier there
might be issues with heap locations as well (windows handling FTH).

Regards,
Bharat

On Thu, Jan 5, 2023 at 5:27 AM R. Matthew Emerson <[email protected]> wrote:

>
>
> > On Jan 4, 2023, at 3:15 PM, Bharat Shetty <[email protected]> wrote:
> >
> > Since two days wx86cl64.exe has been behaving erratically (both the
> version i downloaded and built using gccv4.7.1) it has been crashing
> randomly at startup and emacs is unable to start it with slime. I suspect
> this might be to do with some security patches installed.
> >
> > So I looked into the windows security controls. Turns out windows
> defender lets us configure "exploit protection setting" by configuring the
> following parameters
> >     •
> > control flow guard CFG
> >     • Data Execution Prevention DEP
> >     • Mandatory ASLR (force randomisation for images - force relocation
> of images not compiled with Bottom-up ASLR ) -- off by default for now
> >     • Randomise memory allocation (Bottom-up ASLR) -- on by default
> >     • High Entropy ASLR - needs Bottom-up ASLR to be ON
> >     • validate execution chains (SEHOP)
> >     • validate heap integrity - terminate process when heap corruption
> os detected
> >
> > I observed we can get wxcl8664 to run with 'Mandatory ASLR' and 'High
> Entropy ASLR' turned off and with all other options enabled. So even if gcc
> were to enable us to build non PIE position independant executable, it is
> just a matter of time before no-pie apps and ccl stops running on windows.
> >
> > The only way we can keep ccl running is making the code relocatable
> (PIE) at the earliest. The bright spot is it still runs on linux :)
>
> The x86 port of CCL uses absolute addresses to reference code and other
> data in low memory. Is this what the problem is?
>
> Changing that would be a big hassle.
>
>