如何在Windows上检测X32？ [英] How to detect X32 on Windows?

问题描述

X32允许人们使用在x86_64处理器上运行的32位整数，long和指针编写程序。在某些用例下，使用X32有许多好处。 （X32与X86或X64不同；有关更多详细信息，请参见

Microsoft在预定义的宏列出了常见的可疑对象，例如 _M_X64 和 _M_AMD64 。

如果Microsoft支持X32，那么我怀疑它将成为类似于大型地址空间的选择，或者

Microsoft 实际上是否支持X32（而不是X86和X64）？

• 如果是这样，我如何确定在Windows下选择X32的时间？


• 如果没有，那么为什么英特尔专门调用X32？ Windows平台？

解决方案

问题

Microsoft真的支持X32（而不是X86和X64）吗？

TL; DR答案

答案是不，Microsoft不支持。预处理程序宏不会导致对X32的任何标识，命令行选项和IDE选项都不存在，并且标识此类编译器的字符串也不存在。

< hr>

长答案—第一部分

没有X32的标头字符串

无视以下事实：

• 不存在此功能的官方文档


• 在Visual Studio中没有选项或 cl.exe /？启用/禁用它，并且


• strings -el clui.dll

strings -el％VCINSTALLDIR％\bin\1033 \clui.dll | find Microsoft（R） 也不显示匹配的标头字符串的符号：

  4Microsoft（ R）C / C ++优化编译器版本％s 
-用于Microsoft（R）.NET Framework版本％s 
（Microsoft（R）C / C ++优化编译器
 FMicrosoft（R）C /适用于MIPS R系列
的C ++优化编译器版本％s）Microsoft（R）适用于Renesas SH的C / C ++优化编译器版本％s $ s 
<用于ARM 
的Microsoft（R）C / C ++优化编译器版本％s：用于x86的Microsoft（R）C / C ++标准编译器版本％s 
< Microsoft（R）C / C ++优化编译器版本％适用于x86 
的s适用于PowerPC 
的GMicrosoft（R）32位C / C ++优化编译器版本％s @Microsoft（R）适用于Itanium的C / C ++优化编译器版本％s 
< Microsoft （R）x64 
的C / C ++优化编译器版本％s> Microsoft（R）ARM64 
的C / C ++优化编译器版本％s Microsoft（R）MIPS汇编器
  

在 bin\x86_amd64\1033\clui.dll 和 bin\x86_arm\1033\clui.dll中看到相同的输出文件，所以这不是一个文件根本不包含它。

---

长答案—第二部分

Windows不执行数据模型

我们假设它可以。您将如何检测到它？对于GLIBC，为x32和x86定义了 __ ILP32 __ ，而为amd64定义了 __ LP64 __ ，表示使用的数据模型。此外，将为AMD64体系结构定义 __ x86_64 __ 。如果定义了 __ x86_64 __ 并定义了 __ ILP32 __ ，则说明您使用的是X32 ABI，否则您使用的是AMD64 ABI。对于C，这很重要。如果您使用汇编代码，那么X32 ABI和x86 ABI之间的区别就很重要，因此请检查 __ x86_64 __ 以确定目标体系结构是64位并检查 __ ILP32 __ 确定使用的是32位还是64位ABI。例如：

  #ifdef __x86_64__ 
＃ ifdef __ILP32__ 
 
 //使用X32版本的myfunc（）。 
 extern long myfunc_x32（const char *）; 
 long（* myfunc）（const char *）= myfunc_x32; 
 
＃else / *！__ ILP32__ * / 
 
 //使用AMD64版本的myfunc（）。 
 extern long myfunc_amd64（const char *）; 
 long（* myfunc）（const char *）= myfunc_amd64; 
 
＃endif / * __ILP32__ * / 
 
 / *！__ x86_64__ * / 
 #elif定义__i386__ 
 
 //使用x86版本myfunc（）。 
 extern long myfunc_x86（const char *）; 
 long（* myfunc）（const char *）= myfunc_x86; 
 
 / *！__ i386__ * / 
 #else 
 
 //使用通用版本的myfunc（），因为没有可用的优化版本。 
 long myfunc（const char *）; 
 
 #endif / * __x86_64__ * / 
  

但是，没有宏指示Windows上的数据模型。您针对以下架构之一：

• 32位x86（ _M_IX86 ）


• 64位AMD64（ _M_AMD64 / _M_X64 ）


• （32位？）ARM（ _M_ARM ）

从理论上讲，可以单独使用 _M_AMD64 和 _M_X64 来确定X32是否存在，但是是否 _M_AMD64 已定义， _M_X64 也已定义。

---

长答案—第三部分

坏消息

最后，在寻找任何东西之后，甚至可能是漫长的遗忘的材料，没有证据表明Windows支持或曾经支持Linux之类的X32 ABI编码。预处理程序宏无法帮助识别X32，命令行选项和IDE选项不存在，并且标识此类编译器的字符串也不存在。

---

长答案—新希望破灭了

这些不是您要查找的宏

使用当前存在的宏进行检查，但由于在Windows中不存在X32，因此在这种情况下它不起作用。它与GLIBC检查没有什么不同，尽管如果未定义 __ ILP32 __ 而不是启用X32，但如果未定义 _M_X64 ，则可以启用X32

  #ifdef _M_AMD64 
＃ifndef _M_X64 
＃define ABI_STR  X32 
＃else 
＃定义ABI_STR AMD64 
＃endif 
 #elif定义_M_IX86 
＃定义ABI_STR X86 
 #else 
＃错误不受支持的CPU /体系结构
 #endif 
  

当然，如果<$定义了c $ c> _M_AMD64 ，然后也定义了 _M_X64 ，进一步证明了Windows没有X32。

X32 allows one to write programs using 32-bit integers, longs and pointers that run on x86_64 processors. Using X32 has a number of benefits under certain use cases. (X32 is different than X86 or X64; see Difference between x86, x32, and x64 architectures for more details).

It appears some Windows Enterprise Server supports X32, but I'm having trouble finding more information on it. That's based on some Intel PDFs, like Intel® Xeon® Processor E5-2400 Series-based Platforms for Intelligent Systems:

Microsoft's documentation on Predefined Macros lists the usual suspect, like _M_X64 and _M_AMD64. But it does not appear to discuss an architecture option for X32.

If Microsoft supports X32, then I suspect it is going to be an option similar to large address space aware or terminal service aware.

Does Microsoft actually support X32 (as opposed to X86 and X64)?

• If so, how can I determine when X32 is being selected under Windows?
• If not, then why does Intel specifically call out the X32 platform for Windows?

解决方案

The question

Does Microsoft actually support X32 (as opposed to X86 and X64)?

TL;DR answer

The answer is "No, it's not supported by Microsoft." The preprocessor macros don't lead to any identification of X32, the command line options and IDE options don't exist, and the strings identifying such a compiler don't exist.

---

The long answer — Part I

"There are no header strings for X32"

Disregarding the following facts:

• no official documentation of such a feature exists,
• no option in Visual Studio or cl.exe /? to enable/disable it exists, and
• strings -el clui.dll shows no sign of such an option,

strings -el "%VCINSTALLDIR%\bin\1033\clui.dll" | find "Microsoft (R)" shows no sign of a matching header string either:

4Microsoft (R) C/C++ Optimizing Compiler Version %s
-for Microsoft (R) .NET Framework version %s
(Microsoft (R) C/C++ Optimizing Compiler
FMicrosoft (R) C/C++ Optimizing Compiler Version %s for MIPS R-Series
)Microsoft (R) MIPS Assembler Version %s
CMicrosoft (R) C/C++ Optimizing Compiler Version %s for Renesas SH
<Microsoft (R) C/C++ Optimizing Compiler Version %s for ARM
:Microsoft (R) C/C++ Standard Compiler Version %s for x86
<Microsoft (R) C/C++ Optimizing Compiler Version %s for x86
GMicrosoft (R) 32-bit C/C++ Optimizing Compiler Version %s for PowerPC
@Microsoft (R) C/C++ Optimizing Compiler Version %s for Itanium
<Microsoft (R) C/C++ Optimizing Compiler Version %s for x64
>Microsoft (R) C/C++ Optimizing Compiler Version %s for ARM64
Microsoft (R) MIPS Assembler

The same output is seen in the bin\x86_amd64\1033\clui.dll and bin\x86_arm\1033\clui.dll files, so it's not like that one file simply didn't include it.

---

The long answer — Part II

"Windows doesn't do data models"

Let's suppose it did. How would you detect it? In the case of GLIBC, __ILP32__ is defined for x32 and x86 while __LP64__ is defined for amd64, denoting the data model used. Additionally, __x86_64__ will be defined for the AMD64 architecture. If __x86_64__ is defined and __ILP32__ is defined, then you're using the X32 ABI, else you're using the AMD64 ABI. For C, that's all that matters. If you're utilizing assembly code, that's where the differentiation between the X32 ABI and the x86 ABI matters, hence checking __x86_64__ to determine that the architecture targeted is 64-bit and checking __ILP32__ to determine whether the 32-bit or 64-bit ABI is in use. For example:

#ifdef __x86_64__
# ifdef __ILP32__

// Use X32 version of myfunc().
extern long myfunc_x32 (const char *);
long (*myfunc)(const char *) = myfunc_x32;

# else /* !__ILP32__ */

// Use AMD64 version of myfunc().
extern long myfunc_amd64 (const char *);
long (*myfunc)(const char *) = myfunc_amd64;

# endif /* __ILP32__ */

/* !__x86_64__ */
#elif defined __i386__

// Use x86 version of myfunc().
extern long myfunc_x86 (const char *);
long (*myfunc)(const char *) = myfunc_x86;

/* !__i386__ */
#else

// Use generic version of myfunc() since no optimized versions are available.
long myfunc(const char *);

#endif /* __x86_64__ */

However, there is no macro indicating the data model on Windows. You target one of the following architectures:

• 32-bit x86 (_M_IX86)
• 64-bit AMD64 (_M_AMD64/_M_X64)
• (32-bit?) ARM (_M_ARM)

Theoretically one could use _M_AMD64 and _M_X64 independently to determine whether X32 exists, but if _M_AMD64 is defined, _M_X64 is also defined.

---

The long answer — Part III

"The bad news"

In the end, after searching to find anything, perhaps even long forgotten material, there is no evidence that Windows has supported or ever will support coding for an X32 ABI like Linux. The preprocessor macros don't help in identifying X32, the command line options and IDE options don't exist, and the strings identifying such a compiler don't exist.

---

The long answer — A new hope dashed

"These aren't the macros you're looking for"

One could hypothetically use the currently existing macros to check, but it's not like it helps in this case because X32 for Windows doesn't exist. It's not unlike the GLIBC check, though instead of enabling X32 if __ILP32__ is defined, you enable it if _M_X64 is not defined.

#ifdef _M_AMD64
# ifndef _M_X64
#  define ABI_STR "X32"
# else
#  define ABI_STR "AMD64"
# endif
#elif defined _M_IX86
# define ABI_STR "X86"
#else
# error unsupported CPU/architecture
#endif

Of course, if _M_AMD64 is defined, then _M_X64 is defined too, further reinforcing the evidence that there is no X32 for Windows.

这篇关于如何在Windows上检测X32？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！