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

JF Bastien via cfe-dev cfe-dev at lists.llvm.org
Mon Aug 6 15:01:21 PDT 2018


Hi Charles,

It sounds like you already have some of this implemented? How different is it from -mx32 ? It sounds kinda different, but with some overlap?

Thanks,

JF

> On Aug 6, 2018, at 2:49 PM, Charles Davis via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Resending to the new mailing list address...
> 
> ---------- Forwarded message ----------
> From: Charles Davis <cdavis5x at gmail.com <mailto: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 <mailto: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
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

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


More information about the cfe-dev mailing list