<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Resending to the new mailing list address...</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Charles Davis</b> <span dir="ltr"><<a href="mailto:cdavis5x@gmail.com" target="_blank">cdavis5x@gmail.com</a>></span><br>Date: Thu, Aug 2, 2018 at 5:59 PM<br>Subject: 32-bit pointers and calls from 64-bit code<br>To: Clang Developers List <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>><br><br><br><div dir="ltr"><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial">Hello,</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial">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 style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;text-decoration-style:initial;text-decoration-color:initial">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. 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"><ul><li><font face="arial, helvetica, sans-serif">(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">__i386__</font><font face="arial, helvetica, sans-serif"> et al. as though we were building real 32-bit code.</font></li><li><font face="arial, helvetica, sans-serif">Microsoft's </font><font face="monospace, monospace">__ptr32</font><font face="arial, helvetica, sans-serif"> and </font><font face="monospace, monospace">__ptr64</font><font face="arial, helvetica, sans-serif"> keywords--to distinguish 32-bit and 64-bit pointers.</font></li><li><font face="arial, helvetica, sans-serif">A pragma to choose the default pointer size--with this, we can avoid littering our code with lots of </font><font face="monospace, monospace">__ptr32</font><font face="arial, helvetica, sans-serif"> keywords.</font></li><li><font face="arial, helvetica, sans-serif">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">__attribute__((cdecl32))</font><font face="arial, helvetica, sans-serif">).</font></li><li><font face="arial, helvetica, sans-serif">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">__based</font><font face="arial, helvetica, sans-serif"> extension (which originally supported something like this, I believe) for this purpose.</font></li></ul><div><font face="arial, helvetica, sans-serif"><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">Questions? Comments? Insinuations that I'm off my rocker? We understand if you don't want any of this, but note that a large chunk of my employer's revenue depends on this, so if need be, we'll maintain our own fork. We would prefer, however, that this be upstreamed.</div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="font-size:small;text-decoration-style:initial;text-decoration-color:initial">Chip<br></div></font></div></div><br></div></div>
</div><br></div>