<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 7, 2018, at 4:06 PM, Charles Davis <<a href="mailto:cdavis5x@gmail.com" class="">cdavis5x@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 6, 2018 at 7:39 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><span class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 6, 2018, at 6:34 PM, John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-8410662625807811171m_-2761031161913787442Apple-interchange-newline"><div class=""><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Aug 6, 2018, at 5:49 PM, Charles Davis via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-8410662625807811171m_-2761031161913787442Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div style="font-family:arial,helvetica,sans-serif" class="">Resending to the new mailing list address...</div><div style="font-family:arial,helvetica,sans-serif" class=""><br class=""></div><div class="gmail_quote">---------- Forwarded message ----------<br class="">From: <b class="gmail_sendername">Charles Davis</b> <span dir="ltr" class=""><<a href="mailto:cdavis5x@gmail.com" target="_blank" class="">cdavis5x@gmail.com</a>></span><br class="">Date: Thu, Aug 2, 2018 at 5:59 PM<br class="">Subject: 32-bit pointers and calls from 64-bit code<br class="">To: Clang Developers List <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank" class="">cfe-dev@cs.uiuc.edu</a>><br class=""><br class=""><br class=""><div dir="ltr" class=""><div class=""><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial" class="">Hello,</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial" class=""><br class=""></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial" class="">With Apple's impending 32-bit deprecation, my new employer is having a bit of an existential crisis. We think we've found a way forward, but we need a little help from the compiler to accomplish this.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div>This is a pretty big project to be throwing together like this, but good luck.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class=""><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial" class="">Basically, what we want to do is have code that is technically x86-64 but that can use 32-bit pointers and that can make calls to 32-bit code.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Sure, this is a relatively well-understood problem. The most well-known modern example is Linux's support for "x32".</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class=""><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial" class="">In a separate thread on llvmdev, I asked about LLVM changes we need for this. Here are the corresponding C language extensions we need:</div><div style="text-decoration-style:initial;text-decoration-color:initial" class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">(Possibly) a preprocessor macro to be defined when we're building 64-bit code to be called by 32-bit code. This code, while still technically being 64-bit, needs to look and act like 32-bit code to our clients--so we'd like to define </font><font face="monospace, monospace" class="">__i386__</font><font face="arial, helvetica, sans-serif" class=""> et al. as though we were building real 32-bit code.</font></li></ul></div></div></div></div></div></div></blockquote><div class="">__i386__ generally means, well, the 32-bit Intel target; muddying this by pretending that your variant target is i386 seems like a bad decision. Can you ask your clients to switch to __LP64__ or some other portable pointer-size macro instead?</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class=""><div style="text-decoration-style:initial;text-decoration-color:initial" class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">Microsoft's </font><font face="monospace, monospace" class="">__ptr32</font><font face="arial, helvetica, sans-serif" class=""> and </font><font face="monospace, monospace" class="">__ptr64</font><font face="arial, helvetica, sans-serif" class=""> keywords--to distinguish 32-bit and 64-bit pointers.</font></li></ul></div></div></div></div></div></div></blockquote><div class="">I don't know if we actually support those keywords, but conceptually they're just address spaces so it's not a problem.</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class=""><div style="text-decoration-style:initial;text-decoration-color:initial" class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">A pragma to choose the default pointer size--with this, we can avoid littering our code with lots of </font><font face="monospace, monospace" class="">__ptr32</font><font face="arial, helvetica, sans-serif" class=""> keywords.</font></li></ul></div></div></div></div></div></div></blockquote>Doable. You'll want something that works like the ARC auditing pragmas and tries to force the pragma to stay bounded to a single header, I think.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class=""><div style="text-decoration-style:initial;text-decoration-color:initial" class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">Attributes for various 32-bit calling conventions. We can't use the existing ones, because they are defined not to do anything in 64-bit code. I'll probably define new ones that are just the old ones suffixed with '32' (e.g. </font><font face="monospace, monospace" class="">__attribute__((cdecl32))</font><font face="arial, helvetica, sans-serif" class="">).</font></li></ul></div></div></div></div></div></div></blockquote>Why do you want this? You're recompiling all of your code in this new mode, and the default x86_64 CC is more efficient than all of the specialized i386 CCs. Why not just ignore the attributes?</div><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class=""><div class=""><div style="text-decoration-style:initial;text-decoration-color:initial" class=""><ul class=""><li class=""><font face="arial, helvetica, sans-serif" class="">An attribute to declare that a function pointer must be called far, and to declare the segment selector to use when calling it. We need this to be able to transition to a 32-bit code segment. I'm currently leaning towards (ab)using Microsoft's </font><font face="monospace, monospace" class="">__based</font><font face="arial, helvetica, sans-serif" class=""> extension (which originally supported something like this, I believe) for this purpose.</font></li></ul></div></div></div></div></div></div></blockquote><div class="">Are you really messing around with segments, or are you just trying to be able to to distinguish 32-bit from 64-bit function pointers?</div></div></div></div></blockquote><br class=""></div></span><div class="">Wait, I just put a few things together. Are you planning to perform a far call to existing, i386-compiled code in the same process?</div></div></blockquote><div class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Well... Not exactly.</div></div><div class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br class=""></div></div><div class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">We plan to use the Hypervisor framework to create a VM with 32-bit and 64-bit code segments. We'll then make the entirety of the host process's memory visible inside the guest--the intent is to reduce the number of expensive VM exits. But inside this VM... yes, we intend to make far calls directly to existing i386 code. (We also intend to get called by existing i386 code.) We're trying not to implement an entire OS for this purpose--we want to use the host OS to support as much as we can, which is why we're mapping the host process memory into the VM's physical memory.</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""> That is not going to work without operating system support, and I strongly doubt that macOS has that support — probably not today, and especially not after i386 support is removed.</div></div></blockquote><div class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">I thought so too, but it turns out you don't need a call gate to do this. All you need is the 32-bit segment selector--and on most OSes, that almost never changes, since it's an entry in the GDT. We're well aware that macOS won't even have a 32-bit CS in 10.15--that's why we want to use the Hypervisor framework.</div></div></div></div></div></div></blockquote><div><br class=""></div>I don't know anything about the Hypervisor framework, but what happens if you take an interrupt while in 32-bit code?</div><div class=""><br class=""></div><div class="">John.</div></body></html>