让 LLVM/Clang 16 位对齐答案

【问题标题】：Getting LLVM/Clang to be 16 bit aligned让 LLVM/Clang 16 位对齐
【发布时间】：2011-06-21 18:30:45
【问题描述】：

我正在处理一个遗留项目，其中包含大量可追溯到 OS X 之前的文件。它的数据已经 16 位对齐超过 15 年。我想转向完整的 LLVM 编译，但我似乎无法让 2 字节对齐工作。是否有任何可用的编译器级别选项？（以前使用-malign-mac68k）

我知道这里的#pragma pack(2) 选项。但是，这需要我修改超过 1000 个源文件才能包含它。这是一个最坏的选择，但它看起来像一个黑客。此外，如果这是可能的，那么肯定有一个默认选项来设置对齐方式吗？

【问题讨论】：

您使用的是 clang 还是 llvm-gcc？在 64 位主机上编译时，在 32 位目标上进行 32 位对齐时，clang 比 llvm-gcc 好得多。（-m32 或其他任何东西，都会被 llvm-gcc 忽略）。基本上我建议尝试 clang。
llvm-gcc 似乎尊重 -malign-mac68k，所以如果没有其他解决方案，我们将使用它。我确实希望 llvm-gcc 会在某个时候消失，如果可能的话，我更愿意完全转换。但如果我们找不到解决方案，那可能需要等待。
这是一个伟大而棘手的问题。您可以尝试在 LLVM IRC 聊天中提问。如果不可能，他们可能会告诉你。 llvm.org/docs/#irc
感谢 gcamp 的提示，我会在那边的 IRC 询问。
只是好奇：为什么对齐很重要？

标签： objective-c xcode macos llvm

【解决方案1】：

根据 clang 的消息来源，它确实支持 mac68k 对齐规则。看来现在您只能通过“#pragma options align=mac68k”启用它。如果您对小型 clang hacking 没问题，那么您也可以实现 cmdline 选项并将补丁提交给 clang。

【讨论】：

这既令人鼓舞又令人沮丧。感谢您的提醒！修改它可能超出我的能力（我有时间），所以任何提供帮助的志愿者都会很棒。 =)
今晚有空我会试试的。
好吧，即使这里的某个人没有发生这种情况，我已经向苹果提交了错误报告，因此希望将来会支持它。感谢您的帮助。
苹果可能不会这样做。我最近将苹果错误报告作为他们的开发团队意识到的问题删除。这可能意味着它不会由他们的团队完成。 :(

【解决方案2】：

我建议查看#pragma pack（请参阅http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs.80%29.aspx 和http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html）。它相对容易使用，并且可以与 Apple 提供的任何编译器一起使用。

【讨论】：

我知道这里的#pragma pack(2) 选项。但是，这需要我修改超过 1000 个源文件才能包含它。你是对的，因为它是一个选项，但它似乎是一个 hack。此外，如果这是可能的，那么肯定有一个默认选项来设置对齐方式吗？
你可以用“#pragma pack(2)”“-include”一个文件，我猜……你不想将它应用到系统头文件中。

【解决方案3】：

我使用 ibm 的人在 osx 上编译的最新 gcc/gortran，如果您阅读 gcc 手册，至少有 8 种不同的对齐优化需要考虑，而不仅仅是批量 malign

【讨论】：

【解决方案4】：

由于系统级标头采用默认对齐方式（在大多数情况下，它们没有覆盖对齐方式的指令），因此更改所有内容的对齐方式会中断操作系统调用。因此，您不想这样做。

只需编写一个脚本，将您的#pragma pack(2) 应用于相关源文件，避免使用#includes。它相对容易，不太可能引起不幸的副作用。

【讨论】：

我不确定这是否完全准确，或者我误解了你。目前使用 GCC，我们正在使用 -malign-mac68k 设置编译我们的代码，这意味着项目中的任何内容都被编译为 2 字节对齐。它与系统内容的链接非常好，目前没有问题，我认为 LLVM 级别的设置不会改变这一点——我们已经用 GCC 这样做了。
@slycrel：它可能适用于您碰巧正在使用的调用，但这仍然是一个坏主意，特别是如果您使用其他可能没有明确打包指令的第三方库
我很想知道您为什么认为这是一个“坏主意”。正如我所说，从 MacOS 6.x 到今天，这个程序已经完成了任意数量的系统调用，在 2 字节对齐方面没有任何问题（除了我们自己的愚蠢错误）。你得原谅我有点怀疑，但我愿意听。对于非标准对齐肯定不理想，但我看不出这里有什么特别不正确的地方。除了在自定义结构上小心地从磁盘（或内存结构之间）读取和写入内存块之外，我不认为这是一个问题。
如果您使用具有struct foo { short x; int y; } 的外部库，foo 的布局将在库和您的程序之间有所不同，可能会导致崩溃或其他问题。到目前为止，您可能已经足够幸运地避免了此类问题，但不能保证您将来不会遇到这些问题。这就是为什么我建议您仅将#pragma pack(2) 添加到您自己的代码中，以避免将来出现问题。
是的，我们知道这些类型的问题，并且照常处理它们。实际上，只有在进行块内存操作或写入磁盘时才重要。成员字段访问没有特别改变。但我认为你错过了这样一个事实，即 #pragma pack(2) 和 -malign-mac68k 做同样的事情，只是一个在代码中是明确的，另一个是编译代码时的标志。这个想法是获取编译器级别标志（如果存在）。我认为可能有一些东西，因为有 32 位和 64 位对齐的标志。这是一个模糊的请求，因此是赏金。