【发布时间】：2011-03-10 19:02:18
【问题描述】：
假设所有 32 位库都存在，似乎大多数 32 位应用程序将在 64 位 Linux 上运行。但在我看来，依赖于架构的函数可能存在问题，这里我正在考虑信号和 setjmp/longjmp。我想知道是否有经验的人可以评论哪些功能（如果有）会导致 32 位应用程序与 64 位操作系统不兼容。
【问题讨论】：
标签： c++ linux 32bit-64bit
【发布时间】：2011-03-10 19:02:18
【问题描述】：
即使setjmp 和longjmp 也应该可以正常工作。没有来自用户空间应用程序的特定问题会出现任何问题。实际的 32 位仿真由处理器完成。系统调用是返回 64 位内核的接口，Linux 可以正确处理。
如果应用程序是邪恶的，并将可执行代码发送到另一个 64 位进程执行，那么各种事情都会崩溃。
【讨论】：
对于在 64 位系统上运行的 32 位应用程序来说，最大的问题是程序员错误地假设整数或指针长度，然后用它们做不可移植的事情。 Sun 的this article 中对 C/C++ 程序员需要考虑的问题进行了很好的概述
【讨论】：
-
我见过很多很多项目，当为 x64 编译时，仅仅因为这个问题，就会产生数百个甚至数千个警告。这包括最近的项目，所以没有像“是的，但当时没有 64 位”这样的借口
-
当您想要为 64 位架构重新编译 32 位应用程序时会出现这些问题。但我问的是一个已经用 32 位编译器编译的应用程序。编译器当然已经对指针大小做出了假设！因此，据我了解，正确处理 32 位应用程序取决于 64 位操作系统。
-
你是对的。当然，当编写遗留的 32 位应用程序时，他们不会知道以后可能会在 64 位系统上运行。 64 位操作系统通过其链接器/加载器（例如 ld.so 或 ld.linux.so）必须将地址重新映射到其 64 位进程地址空间以使其正常运行。如果 32 位应用程序写得很好（根据文章），那么一切都应该继续。
-
加载程序知道 32 位可执行文件，但只是退回到在较小空间中加载 4 字节地址。 CPU 和内核处理所有的魔法（指令模拟、页面错误、系统调用）。
-
@theatrus 诚然，我的经验是在 SPARC 上使用 Solaris，它以某种方式做事。我不能说其他架构是如何解决这个问题的。
如果在没有 32 位传统支持的情况下编译 Linux，您的 32 位程序将无法正常运行。
【讨论】：
-
正如我所说，假设所有 32 位库都存在，这意味着内核也构建了 32 位支持 :-)
假设您有必要的 32 位库，在 64 位 Linux 下运行 32 位应用程序实际上只会出现两个问题：
在 64 位内核上由 32 位用户进程使用时，一些用于较少使用的驱动程序的
ioctl()s 无法正常工作；如果 32 位库位于其他位置，则具有硬编码
/usr/lib和/或/lib路径以搜索动态库的应用程序将无法工作。
【讨论】：
让我们举一个 32 位应用程序的例子，它有一个主模块并加载一个 32 位依赖的 dll。如果您同时迁移主模块和 32 位相关 dll，则该应用程序在 64 位机器上运行良好。但是如果您只迁移主模块，即使存在，它也无法从 64 位机器加载 64 位依赖 dll。 原因是——
数据在内存中的不同对齐方式
数据类型大小的差异
请参考：
http://dev-faqs.blogspot.com/2008/03/accessing-32-bit-dlls-from-64-bit-code_02.html
这可能就是你要找的东西！
【讨论】：