1

假设以下一段 C++ 代码：

char huge[0x900000000];
char large[0x90000000];

在 OS X 上，这无法编译 ( g++ -c filename.cc)：

….s:4:zerofill size (2415919104.) <0! Ignored.
….s:4:Rest of line ignored. 1st junk character valued 44 (,).

查看汇编代码（g++ -S filename.cc）：

    .section    __TEXT,__text,regular,pure_instructions
    .globl  _huge
.zerofill __DATA,__common,_huge,1,5
    .globl  _large
.zerofill __DATA,__common,_large,2415919104,5

.subsections_via_symbols

这是 Apple Mountain Lion 上的系统 gcc，即i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00). 我还通过 MacPorts 安装了一个版本：g++-mp-4.8 (MacPorts gcc48 4.8.2_0) 4.8.2. 有了它，我得到了基本相同的错误消息，尽管生成的程序集现在看起来像这样：

    .globl _huge
    .zerofill __DATA,__pu_bss5,_huge,38654705664,5
    .globl _large
    .zerofill __DATA,__pu_bss5,_large,2415919104,5
    .constructor
    .destructor
    .align 1
    .subsections_via_symbols

在我看来，所有这些都至少像一个错误：显然，汇编器确实将该大小解释为有符号的 32 位数量，而不考虑溢出。不过，我不确定在哪里报告这个问题：这是一个 GCC 错误，要使用 GCC 错误跟踪器报告吗？或者它是苹果汇编程序中的一个错误，我应该尝试针对 XCode 或类似的东西报告它？如果是这样，具体如何？或者这实际上是这里使用的 LLVM 软件，我应该在那里报告吗？

gcc那么系统在其汇编输出中生成错误大小的事实又如何呢？由于 MacPorts 版本处理得更好，我认为 GCC 开发人员在此期间已经修复了这个问题，Apple 最终可能会接受这个问题。你同意这一点，还是我应该在某个地方提交第二份报告来解决这个问题？

4

1 回答 1

0

Apple 工程师以这种方式向我的错误报告 #15977897 报告：

llvm-gcc 几年来一直不受支持。请使用铿锵声。

使用 clang 确实有效。至少没有错误消息，并且目标文件似乎确实有一个__DATA用标志标记的正确大小的段S_ZEROFILL。这是我使用MachOView工具发现的。clang 生成的汇编代码看起来也很正常：它对两个变量都有正确的大小。

于 2014-02-07T08:46:41.007 回答