<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Hi,<br></div><div dir="ltr"><div dir="ltr"><div><br></div><div>I had not mentioned previously the reason I had added -no-pie. The executable used to wperror out after calling VirtualProtect in pmcl-kernel.c:remap_spjump() function. The error was <span style="background-color:transparent;font-family:inherit;font-style:inherit;font-variant-ligatures:inherit;font-variant-caps:inherit;font-weight:inherit;white-space:inherit">ERROR_INVALID_ADDRESS </span><span style="background-color:transparent;font-family:inherit;font-style:inherit;font-variant:inherit;font-weight:inherit;white-space:inherit;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;font-size:13px;vertical-align:baseline;box-sizing:inherit">487</span><span style="background-color:transparent;font-family:inherit;font-style:inherit;font-variant-ligatures:inherit;font-variant-caps:inherit;font-weight:inherit;white-space:inherit"> (</span><span style="background-color:transparent;font-family:inherit;font-style:inherit;font-variant:inherit;font-weight:inherit;white-space:inherit;margin:0px;padding:0px;border:0px;font-stretch:inherit;line-height:inherit;font-size:13px;vertical-align:baseline;box-sizing:inherit">0x1E7</span><span style="background-color:transparent;font-family:inherit;font-style:inherit;font-variant-ligatures:inherit;font-variant-caps:inherit;font-weight:inherit;white-space:inherit">). </span>After I added -no-pie (strangely -Wl,--no-pie or -fno-pie doesnt work) this got sorted. Some people say this disables ASLR however gnu ld doc is not very clear on this. However VirtualProtect working means this is needed.<div><br></div><div>Today i added the following flags </div><div><ul><li>-Wl,--disable-high-entropy-va  ;; --high-entropy-va - Image is compatible with 64-bit address space layout randomization (ASLR).This option is enabled by default for 64-bit PE images.</li><li>-Wl,--disable-dynamicbase ;; --dynamicbase - The image base address may be relocated using address space layout randomization (ASLR). This feature was introduced with MS Windows Vista for i386 PE targets.</li><li>-Wl,--disable-nxcompat ;; --nxcompat - The image is compatible with the Data Execution Prevention.</li></ul></div><div>However these do not change anything and the wx86cl64 crashes at exactly the same position(calculate_relocation () at ../x86-gc.c:1571). When I debug the executable the image base address(0x12000) , text start address(0x21000) amongst other addresses are the same across multiple executions. Would these not change if ASLR is active?</div><div><br></div><div>This may not be related to ASLR as ASLR changes the image base and section start addresses at load time. As far as I understand ASLR does not change the base during execution. Whatever is causing this is changed behaviour of gcc/ld. Microsoft site clearly mention ASLR is to be opted in by the developer. If this was an OS change the downloaded bits should have the same issue. Another question is if ASLR in Windows were to cause re-initialisation of globals who could use it ?</div><div><br></div><div>Regards,</div><div>Bharat</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Dec 30, 2022 at 3:05 AM Carl Shapiro <<a href="mailto:carl.shapiro@gmail.com" target="_blank">carl.shapiro@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The feature is known as ASLR in both Windows and Linux<br></div><div><br></div><div><a href="https://learn.microsoft.com/en-us/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10#address-space-layout-randomization" target="_blank">https://learn.microsoft.com/en-us/windows/security/threat-protection/overview-of-threat-mitigations-in-windows-10#address-space-layout-randomization</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 29, 2022 at 12:43 PM Tim McNerney <<a href="mailto:mc@media.mit.edu" target="_blank">mc@media.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">I wonder if you need to <u>turn off</u> Windows 10’s new-ish, nondeterministic memory allocation policy. We have run into this with other Lisps. I don’t remember the correct terminology for this malware countermeasure or the name of the configuration flag. Sorry. Can someone else chime in?<br><br><div dir="ltr">--Tim</div><div dir="ltr"><br><blockquote type="cite">On Dec 29, 2022, at 13:49, Bharat Shetty <<a href="mailto:bshetty@gmail.com" target="_blank">bshetty@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi,<div><br></div><div>I built ccl (downloaded the 1.12.1 zip file from github)on </div><div><ul><li>Windows 10 (cygwin)</li><li>gcc version 11.3.0 </li><li>ld/binutils version 2.39</li><li>debug flag changed to -g3 in Makefile</li><li>code optimisation level set to -O0 (zero) also in Makefile</li></ul></div><div><br></div><div>When the exe was built i got a message that section /1, /8 and /32 are before text. I altered the pei-x86-64.x to include the new debug sections(upto dwarf 5). For this i generated the default script running ld --verbose. retained .Copied .spfoo from the original, removed KEEP() and most of the SORT() unless it was present in the original file. Besides this I had to add <i><b>-no-pie and -Wl,--allow-multiple-definition</b></i> to the build rule for wx86cl64.exe target. I have not made any changes to the source code. This got an exe that starts. </div><div><br></div><div>However every time I run this, it crashes at calculate_relocation in x86-gc.c. The back trace is as follows:</div><div>#0  0x0000000000031d56 in calculate_relocation () at ../x86-gc.c:1571<br>#1  0x000000000002ea15 in gc (tcr=0x5acebc0, param=0) at ../gc-common.c:1821<br>#2  0x000000000003a170 in gc_from_tcr (tcr=0x5acebc0, param=0) at ../x86-exceptions.c:3014<br>#3  0x000000000003a06b in gc_like_from_xp (xp=0x25f6f570, fun=0x3a126 <gc_from_tcr>, param=0) at ../x86-exceptions.c:2970<br>#4  0x000000000003a1ce in gc_from_xp (xp=0x25f6f570, param=0) at ../x86-exceptions.c:3026<br>#5  0x0000000000035c0f in allocate_object (xp=0x25f6f570, bytes_needed=16, disp_from_allocptr=13, tcr=0x5acebc0, crossed_threshold=0x25f6f1ec) at ../x86-exceptions.c:171<br>#6  0x0000000000036f26 in handle_alloc_trap (xp=0x25f6f570, tcr=0x5acebc0, notify=0x25f6f1ec) at ../x86-exceptions.c:665<br>#7  0x0000000000037f15 in handle_exception (signum=11, info=0x25f6f4d8, context=0x25f6f570, tcr=0x5acebc0, old_valence=0) at ../x86-exceptions.c:1215<br>#8  0x0000000000038cf3 in windows_exception_handler (exception_pointers=0x25f6f4c0, tcr=0x5acebc0, signal_number=11) at ../x86-exceptions.c:2150<br>#9  0x00000000000438dd in windows_switch_to_foreign_stack () at ../x86-asmutils64.s:263<br>#10 0x0000000025f6f4c0 in ?? ()<br></div><div><br></div><div>This happens after start_lisp is called. By the time the code reaches gc.c global_reloctab is reset (set to 0x7cfe000000 before entering start_lisp). Due to this GCrelocptr is also set to 0x0 in gc-common.c. This results in relocptr being set to 0x0 in calculate_relocation. Also GCndynamic_dnodes_in_area is also 0 at this point(in the downloaded version it is 2048 at this point). </div><div><br></div><div>Does anyone know why these global variables are reset ? And how can I fix this? I suspect this is because of the newer versions of gcc and ld.</div><div><br></div><div>Regards,</div><div>Bharat</div></div>
</div></blockquote></div></blockquote></div>
</blockquote></div></div>
</div></div>