在 Linux (gcc) 中混合 32 位和 64 位库 [英] Mixing 32 and 64-bit Libraries in Linux (gcc)

问题描述

我有一个专为 Linux(使用 gcc)构建的 32 位二进制 C .so(由供应商提供)，我需要链接到 64 位 C/C++ 应用程序(我正在开发).有什么办法可以从我的应用程序访问这个库吗?

I have a 32-bit binary-only C .so (provided by a vendor) built for Linux (using gcc), that I need to link to a 64-bit C/C++ application (which I am developing). Is there any way to access this library from my application?

我知道需要小心处理 .so 中的参数和指向函数的指针，而且我知道很久以前这被认为基本上是不可能的(比如 这篇帖子).我希望情况有所改变.

I know there will need to be care taken to handle arguments and pointers to functions inside the .so, and I know that long ago it was deemed basically impossible (like this post). I'm hoping the situation has changed.

推荐答案

也许可以将一些汇编粘合代码组合在一起，将函数参数和返回值从一个模块转换为另一个模块，并翻转处理器模式.可能会破解链接器，因此它不会立即拒绝它(或破解 .so 文件以便链接器不知道).而且您必须教 64 位动态链接器如何进行 32 位重定位，等等，等等.

It might be possible to hack together some assembler glue code to translate the function parameters and return values from one module to the other, and flip the processor mode. It might be possible to hack the linker so it doesn't just reject it out of hand (or hack the .so file so the linker doesn't know). And you'd have to teach the 64-bit dynamic linker how to do 32-bit relocations, and so on, and on, and on.

但是，当您命中 32 位范围之外的指针时会发生什么?话说回来，如果 32 位代码在 64 位地址加载会发生什么?现在必须教导内核在低内存地址中加载这个 64 位程序，这反而违背了首先将其设为 64 位的意义.

But, what happens when you hit a pointer outside the 32-bit range? Come to that, what would happen if the 32-bit code got loaded at a 64-bit address? Now the kernel would have to be taught to load this 64-bit program in low memory addresses, which rather defeats the point of making it 64-bit in the first place.

然后您必须安排该库链接到 32 位 libc，但是在一个项目中拥有两个 libc 可能已损坏.也许 32 位库可以使用 64 位 libc?但是，现在您需要担心的不仅仅是函数参数:系统类型的大小都是错误的.嗯，内核对来自 32 位和 64 位进程的系统调用的响应可能不同.不好.

Then you'd have to arrange for that library to link against the 32-bit libc, but having two libc in one project is probably broken. Maybe the 32-bit library could use the 64-bit libc? But, now that's not just function parameters you have to worry about: the system types are all the wrong size. Hmmm, and the kernel probably responds differently to syscalls from 32-bit and 64-bit processes. Not good.

(而且，我什至不确定是否可以在没有内核帮助的情况下在 32 位和 64 位 ISA 之间切换?)

(And, I'm not even sure it's even possible to switch between the 32-bit and 64-bit ISA without assistance from the kernel?)

不，我很确定这几乎是不可能的，以至于没有人愿意做这项工作.而且，随着 64 位和 32 位越来越少、越来越不有趣，情况变得不太可能改变，而不是更多.

No, I'm pretty sure this is close enough to impossible that nobody wants to do the work. And, with the world going increasingly 64-bit and 32-bit getting less, and less interesting, the situation is getting less likely to change, not more so.

IPC 选项听起来不太有趣.如果我是你，我会认真地质疑为什么我的新项目必须是 64 位的.

The IPC option doesn't sound like much fun. If I were you I'd be seriously questioning why my new project has to be 64-bit.

这篇关于在 Linux (gcc) 中混合 32 位和 64 位库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！