将结构对齐到 64 位端口代码

发布于 2024-07-13 17:23:55 字数 435 浏览 9 评论 0原文

我有一个 32 位 .NET 程序集,它可以 PInvokes 进入 C 层。 我想将此程序集移植到 64 位。 我读过很多与移植到 64 位相关的文档,所有这些似乎都表明,如果我们要使用结构体,就需要注意对齐。

我有一个与结构对齐相关的一般性问题,想首先澄清这一点,这样我就不会错过任何东西。

假设我有一个 C 入口点,它接受一个结构指针并基本上填充其中的值。 此 C 代码没有任何打包指令,并且我将所有 .NET 结构与 pack=8 对齐。 因此,如果我传递一个具有相邻整数的结构,我认为解释 .NET 层中填充的数据可能会出现问题,因为默认情况下 C 将使用 pack=4,而我们在 .NET 中将该结构解释为 pack=8层,所以认为这可能会导致问题。 但事实似乎并非如此。 数据似乎解释得很好。

谁能解释这种行为?

谢谢, 尼兰詹

I have a 32-bit .NET assembly which PInvokes into the C layer. I want to port this assembly to 64-bit. I have read many documents related to porting to 64-bit, all of which seems to suggest that we need to take care of the alignment if we are to use structures.

I had a general question related to structure alignment and wanted to clarify that first so that I dont miss anything.

Suppose I have a C entry point which accepts a struct pointer and basically fills up the values inside. This C code does not have any packing directives and I have all the .NET structs aligned to pack=8. So if I pass a structure with adjacent ints, I thought it could be a problem interpreting the data populated in the .NET layer, as the C by default would use pack=4 and we are interpreting the struct as pack=8 in .NET layer, so thought it could cause a problem. But it doesn't seem to be the case. The data seems to be interpreted fine.

Can anyone explain this behavior?

Thanks,
Niranjan

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

最单纯的乌龟 2024-07-20 17:23:55

默认情况下,结构或联合的成员在其自然边界上对齐; 一个字节表示一个字符,两个字节表示一个短整型,四个字节表示一个整数,等等。如果存在 n,则它必须是 2 的幂,指定任何结构或联合成员的最严格的自然对齐。

例如,#pragma pack(2) 在两个字节边界上对齐 int、long、long long、float、double、long double 和指针,而不是它们的自然对齐边界。 如果 n 等于或大于平台上最严格的对齐方式(x86 上为 4,x86 上为 8)
SPARC v8 和 SPARC v9 上为 16),该指令具有自然对齐的效果。

我不确定 x86 架构是否支持 8 字节对齐,即使它们支持 64 位环境。 毕竟,64 位平台上的 4 字节对齐不会造成任何损害。

您还可以使用:#pragmaalign 8(变量)来告诉编译器您希望如何对齐全局或静态变量。

By default, members of a structure or union are aligned on their natural boundaries; one byte for a char, two bytes for a short, four bytes for an integer etc. If n is present, it must be a power of 2 specifying the strictest natural alignment for any structure or union member.

For example, #pragma pack(2) aligns int, long, long long, float, double, long double, and pointers on two byte boundaries instead of their natural alignment boundaries. If n is the same or greater than the strictest alignment on your platform, (four on x86, eight on
SPARC v8, and 16 on SPARC v9), the directive has the effect of natural alignment.

I'm not sure if the x86 architecture supports 8-byte alignment even though they support a 64-bit environment. After all, 4-byte alignment on a 64-bit platform wouldn't harm anything.

You can also use: #pragma align 8 (variable) to tell the compiler how you want a global or static variable aligned.

猫九 2024-07-20 17:23:55

我看到这篇 msdn 文章
http://msdn.microsoft.com/en-us /library/aa366769(VS.85).aspx

它表明指定大于类型自然对齐的打包级别不会更改类型对齐。 因此,由于我提到的上述情况中的自然对齐方式是 4,因此将填充设置为 8 并不会真正改变结构的对齐方式。 这解释了这种行为。

I came across this msdn article
http://msdn.microsoft.com/en-us/library/aa366769(VS.85).aspx

It suggests that specifying a packing level larger than the natural alignment of a type does not change the type alignment. So since the natural alignment in the above case I mentioned is 4, setting the packing to 8 does not really change the alignment of the structure. This explains the behavior.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文