首页 > 解决方案 > 结构在共享对象中的大小与在二进制调用共享对象中的大小不同

问题描述

我正在将一个大型(古老的)程序转换为一个新的操作系统和驱动程序。该程序和驱动程序是在 64 位操作系统上运行的 32 位。我在尝试打开驱动程序时遇到了一些困难。

经过一些测试,我确定我正在转换的程序认为某个结构是 19412 字节,而驱动程序认为该结构是 19416 字节。当驱动程序尝试将传递给它的结构的内容归零时,这反过来会导致覆盖指针的内容,从而导致我的其余问题。

我试图弄清楚为什么驱动程序和程序在结构大小上存在分歧。

驱动程序 Makefile 看起来像这样(由于连接问题,手动重新输入,所以请原谅拼写错误):

cc -g  -m32 -c -fPIC -I../inc -D_UNIX -D_LINX -D_EEEI -D_FILE_OFFSET_BITS=64 ../lib/icelib.c
cc -g -pthread -m32 -shared -lm -o ../lib/libice.so icelib.o 
ar -rcs ../lib/libice.a icelib.o

cc -g -m32 -I../inc -D_UNIX -D_LINX -D_EEEI -lm -o ice ice.c ../lib/libice.so

运行它的程序稍微复杂一些。因为二进制文件会动态加载 SO,而 SO 又会调用 libice.so 驱动程序,而 So 是使用多个对象和 .a 文件构建的。实际调用驱动程序的代码包含在 PICbrd.o 文件中:

g++ -Dpthread -D_REENTRANT -DINC_TYPEDEFS -DLINUX -DICEPIC -D__FILENAME__=\"PIC6brd.cpp\" -c -g -DDEBUG -pg -m32 -Wall -D__linux__ -D__BUILD_VERS__='"3.1"' -D__BUILD_NUMBER__="'3.8"' -D__BUILD_TIME__''""' -D__cplusplus -Dcsp_SHARED -03 c/src/PIC6brd.cpp -o c/obj/PIC6brd.o 

上面还有大量的 -I ,我不包括在内只是因为它使命令的大小增加了三倍。包含指向用于构建 icelib.so 的同一个库

只是为了进行健全性测试,我尝试在 icelib.so 构建脚本中用 G++ 替换 CC。我收到了更多警告,但它并没有改变 SO 中结构的大小。

什么可能导致两个二进制文件具有不同的结构大小?

编辑:有问题的结构包含在这里,并且在内部引用了许多其他结构。虽然它主要包含 int_4 和 int_1 它确实包含一些浮点数和双精度数,它们的大小取决于架构。但是,我使用 64 位构建脚本编译了驱动程序并检查了那里的结构的大小,它明显更大(我相信是 19782)。似乎 32 位到 64 位转换的问题会导致超过 4 位的差异。我还在所有看起来相关的二进制文件上运行了“文件”命令,它们都报告为 32 位。

标签: c++ccompilation

解决方案


推荐阅读