[cfe-dev] Fwd: 32-bit pointers and calls from 64-bit code

[Charles Davis via cfe-dev]

Resending to the new mailing list address...

---------- Forwarded message ----------
From: Charles Davis <cdavis5x at gmail.com>
Date: Thu, Aug 2, 2018 at 5:59 PM
Subject: 32-bit pointers and calls from 64-bit code
To: Clang Developers List <cfe-dev at cs.uiuc.edu>


Hello,

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.

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:

   - (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 __i386__ et al. as though we were building real
   32-bit code.
   - Microsoft's __ptr32 and __ptr64 keywords--to distinguish 32-bit and
   64-bit pointers.
   - A pragma to choose the default pointer size--with this, we can avoid
   littering our code with lots of __ptr32 keywords.
   - 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. __attribute__((cdecl32))).
   - 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 __based extension (which originally
   supported something like this, I believe) for this purpose.

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.

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180806/cb44dd8e/attachment.html>