<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=""><br class=""><div><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" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; 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" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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 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><div>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? 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><br class=""></div><div>Something like an x32 ABI can help if you have the ability to recompile the code and are just concerned about it not being 64-bit-safe or can't afford the memory overhead of 64-bit pointers, but it won't let you actually interoperate with i386 code.</div><div><br class=""></div><div>John.</div><br class=""></body></html>