<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Yoshiki, Tim, Subbu,<div><br></div><div> ARMv8 is cool; but Linux is a hydra. In getting the JIT to work with ARMv8 I went with the first full 64-bit ARMv8 platform I could access, Manjaro on Raspberry Pi 4. I now also have an Apple Silicon Mac Mini.</div><div><br></div><div>The OS can impose radically different constraints on the JIT. In Mankato it is impossible to derive an executable region from mmap that is at the same time writable. On MacOS it is possible, but the VM needs a capability conveyed through its Info.plist and baked in when the app bundle is signed.</div><div><br></div><div>Other linuxes for Pi4 May impose different constraints. As I only have these two variants I need your help in dealing with differing constraints on these other platforms.</div><div><br></div><div>So what of these constraints? Manjaro’s prevents one from simply allocating the code zone as read+write+execute. So I have to allocate it read+execute and map it elsewhere in the address space as read+write and do all code zone modification (code generation, send-site editing/dynamic-linking/garbage-collection updating, compaction) through this second mapping. To enable that scheme the VM must be compiled with <span style="caret-color: rgb(3, 47, 98); color: rgb(3, 47, 98); font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, monospace; font-size: 12px; white-space: pre; -webkit-text-size-adjust: 100%; background-color: rgb(255, 255, 255);">-DDUAL_MAPPED_CODE_ZONE=1. </span>This is enabled in the mvm scripts in build.linux64ARMv8/squeak.cog.spur. I need to know if the dual mapping scheme is needed on other 64-bit distros. </div><div><br></div><div>So can you take a look, try both variants and report back? The allocation of the code zone and it’s remapping is done via mmap calls in platforms/unix/vm/sqUnixSpurMemory.c.</div><div><br></div><div>I have a small C test file that I used to experiment with copying a function into mmapped executable memory that I can post if you need to investigate why mmap might refuse to map write+execute and try and evade the restrictions it imposes.</div><div><br><div dir="ltr"><span style="background-color: rgba(255, 255, 255, 0);">_,,,^..^,,,_ (phone)</span></div><div dir="ltr"></div><div dir="ltr"><br><blockquote type="cite">On Oct 29, 2020, at 3:29 AM, K K Subbu <kksubbu.ml@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On 29/10/20 4:52 am, tim Rowledge wrote:</span><br><blockquote type="cite"><span>There*is* a 64 bit version of Raspberry PI OS that is currently in</span><br></blockquote><blockquote type="cite"><span>late-beta. That would need a VM from the opensmalltalk-vm ▸</span><br></blockquote><blockquote type="cite"><span>build.linux32ARMv6 ▸ squeak.stack.spur tree and of course a 64</span><br></blockquote><blockquote type="cite"><span>bit image.</span><br></blockquote><span></span><br><span>Ubuntu released their 64-bit desktop versions for Raspberry Pi 4 just last week:</span><br><span></span><br><span> https://ubuntu.com/raspberry-pi</span><br><span></span><br><span>introduction and installation</span><br><span> https://youtu.be/0pT4-RcTERU</span><br><span></span><br><span>direct link</span><br><span> http://cdimage.ubuntu.com/ubuntu/releases/20.10/release/</span><br><span></span><br><span>HTH .. Subbu</span><br></div></blockquote></div></body></html>