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

これはすべて、少なくとも 1 つのバグのように見えます。明らかに、アセンブラは、オーバーフローに関係なく、そのサイズを符号付き 32 ビット量として解釈します。ただし、この問題をどこに報告すればよいかわかりません。これは GCC バグであり、GCC バグ トラッカーを使用して報告する必要がありますか? それとも Apple アセンブラーのバグですか? 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 に答える