コグノスケ

クロスビルド用ツールチェーン - GCC 10.0にしたらハマった

目次: GCC

新し目のAArch64のクロスコンパイル用ツールチェーンを作ろうとして、かなりハマったのでメモしておきます。

基本的には前回（2019年4月29日の日記参照）ご紹介した手順でビルドします。GCCとglibcのコードを変えなくて良い組み合わせは下記の通りです。特に新しいバージョンを使う理由がなければ、この組み合わせが無難です。

• gcc: 8.3.0 (tag: releases/gcc-8.3.0)
• glibc: 2.28 (tag: glibc-2.28)

私は新しいGCCが使いたかったので、HEADにしました（バージョン的には10.0相当）。どうやらGCCのエラーチェックが厳しくなるらしく、glibcのビルドが通らなくなります。たくさんエラーが出ますが、一例を挙げると、下記のようなエラーです。

./../include/libc-symbols.h:534:26: error: '__EI___errno_location' specifies less restrictive attributes than its target '__errno_location': 'const', 'nothrow' [-Werror=missing-attributes]
  534 |   extern __typeof (name) __EI_##name \
      |                          ^~~~~

エラーはglibcを新しくすると解決されるかと思いきや、よりおかしなことになります。例えばGCC 8.3のままglibc 2.30（おそらく2.29でも同じ症状が出る）にすると、下記のような変なエラーが出ます。

crosstool-builder-new-aarch64/buildroot/lib/gcc/aarch64-unknown-linux-gnu/8.3.0/../../../../aarch64-unknown-linux-gnu/bin/ld: crosstool-builder-new-aarch64/build/glibc/support/links-dso-program.o: Relocations in generic ELF (EM: 62)
crosstool-builder-new-aarch64/buildroot/lib/gcc/aarch64-unknown-linux-gnu/8.3.0/../../../../aarch64-unknown-linux-gnu/bin/ld: crosstool-builder-new-aarch64/build/glibc/support/links-dso-program.o: Relocations in generic ELF (EM: 62)
...

エラーの原因となっているオブジェクトlinks-dso-program.oを調べると、AArch64向けにビルドしているにも関わらず、なぜかx86_64用のオブジェクトが生成されています。

build/glibc/support$ file *.o

echo-container.o:    ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped
links-dso-program.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped    ★★★★これ★★★★
shell-container.o:   ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped
stamp.o:             empty
test-container.o:    ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped
true-container.o:    ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped

いったい何ですかね、これ。バグなのか、仕様なのかわかりません……。

GCC 10.0とglibc 2.30の組み合わせでビルドする方法

GCCとglibcをお互い最新にした組み合わせ、すなわち下記の組み合わせにしたとき、

• gcc: 10.0 (HEAD)
• glibc: 2.30 (tag: glibc-2.30)

先ほど説明した、両方のエラーに遭遇してビルドできませんので、glibcにパッチを当ててビルドエラーを回避します。

まずはコンパイルエラーを無視するパッチです。本来はエラーを無視するのではなく、エラーが指摘している事項を直すべきですけど、今回の主眼ではないのと、いずれglibc本家が直るだろうことを期待しておきます。

diff --git a/Makeconfig b/Makeconfig
index fd36c58c04..106688e210 100644
--- a/Makeconfig
+++ b/Makeconfig
@@ -916,7 +916,8 @@ ifeq	"$(strip $(+cflags))" ""
 endif	# $(+cflags) == ""
 
 +cflags += $(cflags-cpu) $(+gccwarn) $(+merge-constants) $(+math-flags) \
-	   $(+stack-protector)
+	   $(+stack-protector) \
+	   -Wno-zero-length-bounds -Wno-array-bounds -Wno-maybe-uninitialized
 +gcc-nowarn := -w
 
 # Each sysdeps directory can contain header files that both will be

次のlinks-dso-programはコミットログを見る限り、テストのサポート用ライブラリなので、とりあえず無くても動くはずです。ビルド自体をやめるパッチをあてます。

diff --git a/support/Makefile b/support/Makefile
index ab66913a02..19c3de2043 100644
--- a/support/Makefile
+++ b/support/Makefile
@@ -184,12 +184,12 @@ CFLAGS-support_paths.c = \
 		-DSBINDIR_PATH=\"$(sbindir)\" \
 		-DROOTSBINDIR_PATH=\"$(rootsbindir)\"
 
-ifeq (,$(CXX))
-LINKS_DSO_PROGRAM = links-dso-program-c
-else
-LINKS_DSO_PROGRAM = links-dso-program
-LDLIBS-links-dso-program = -lstdc++ -lgcc -lgcc_s $(libunwind)
-endif
+#ifeq (,$(CXX))
+#LINKS_DSO_PROGRAM = links-dso-program-c
+#else
+#LINKS_DSO_PROGRAM = links-dso-program
+#LDLIBS-links-dso-program = -lstdc++ -lgcc -lgcc_s $(libunwind)
+#endif
 
 ifeq (yes,$(have-selinux))
 LDLIBS-$(LINKS_DSO_PROGRAM) += -lselinux

クロスコンパイル環境は、各モジュールのバージョンアップですぐ壊れてしまって辛いです。ARMがこれだけ覇権を握っているにも関わらず、gccもglibcもあまりチェックしてないんですかね……？？

後日追記

わざわざMakefileを書き換えなくてもmake LINKS_DSO_PROGRAM= のように、make実行時にLINKS_DSO_PROGRAM変数の値を強制的に空文字列に上書きすれば回避可能でした。理由は昔の日記で書いた通り（2019年9月17日の日記参照）、コマンドラインからの変数指定はMakefile内の代入より強いからです。

Makefile書き換えよりは多少スマートですけども、クロスコンパイルの時だけこんな指定が必要なのは妙ですね。まだ何か見落としているんでしょうかね？

C言語の未定義動作と最適化

目次: C言語とlibc

くそ長いですが、C言語の未定義動作怖いね、printfでタイミング以外も動き変えられるよ、という話です。

環境ですがx86_64向けDebian GNU/Linux 9.2で実行しています。またGCCのバージョンはgcc (Debian 9.2.1-22) 9.2.1 20200104です。

未定義動作のため、コンパイラの種類や、GCCのバージョンにより結果が変わると思われます。お家のマシンで試すならご留意ください。

1番目の実験

この日記の最後に貼ったプログラム（このプログラムをコンパイルすると、激しい警告が出ます）をgcc -Wall -O2 a.c && ./a.outのように実行すると、

0: 0 0 0
1: 0 1 0
2: 0 2 0
3: 0 3 0
4: 0 4 0
...
47: 0 47 0
48: 0 48 0
49: 0 49 0
1770: 1770

こうなります。0〜59の和は1770です。あってます。良かったですね。

なに？そういう問題じゃない？「なぜarray終端を超えてguard2にバッファオーバーランしない？」と考えた方、するどいです。しかし世の中そう単純ではありません。

2番目の実験

10行目のprintfのコメントを外してローカル変数のアドレスを表示させると、

0x7ffd9b348a10 0x7ffd9b348ae0 0x7ffd9b348bb0
0: 0 0 52
1: 0 1 53
2: 0 2 54
3: 0 3 55
4: 0 4 56
...
45: 0 45 0
46: 0 46 0
47: 0 47 0
48: 0 48 0
49: 0 49 0
1770: 1770

こうなります。突然オーバーランするようになりました。printfが何かしたんでしょうか、不思議ですね？

3番目の実験

どうしてforループを無意味に2分割したのか？くっつけてみたらわかります。Segmentation Fault します。

0: 0 0 0
1: 0 1 0
2: 0 2 0
3: 0 3 0
4: 0 4 0
...
45: 0 45 0
46: 0 46 0
47: 0 47 0
48: 0 48 0
49: 0 49 0
Segmentation fault

もう意味不明ですよね。何が起こっているんでしょう？

タネ明かし

この60回のforループは「配列の終端を超えたアクセス」がC言語仕様上の未定義動作なので、何が起きても正しい、つまりどの結果も正しいです。

これだけだと、何言ってんのか意味不明だと思うので「printf有効/無効」「forループ1つ/2つ」に着目して説明します。

1番目の実験（printf無効、forループ2つ）

プログラムを見るとguard1, guard2に対してmemset 0した後、参照のみで代入しません。コンパイラはguard1, guard2をスタックに配置せず、配列への参照（guard1[i], guard2[i]）は全て「定数の0」に置換します。
（GIMPLEを見たら033t.fre1で0に置換されるようです）
このときarrayのバッファオーバーランはスタックに退避されているレジスタ値などを書きつぶしますが、ギリギリ続行できています。

2番目の実験（printf有効、forループ2つ）

1番目と変わりないと思いきや、printfがguard1, guard2のアドレス参照をするため、定数の0に置換すると返せるアドレスがなくなり結果が変わってしまいます。このため、guard1, guard2はスタックに配置されます。
このときarrayのバッファーオーバーランは隣に配置されたguard2を書きつぶします。

3番目の実験（printf無効、forループ1つ）

いわゆる偶然の結果です。1番目と同様にguard1, guard2はスタックに配置されず、arrayのバッファオーバーランによりスタックに退避したレジスタ値などが壊れます。forループが1つ減ったことでスタックに退避されるレジスタが1つ減って（8バイト分余裕がなくなる）、1番目の実験でギリギリリターンアドレスを壊されずに耐えていたものが、耐えられなくなります。

3番目の実験の裏打ちとして、試しにループ回数を80回くらいにするとforループが1つだろうが2つだろうが、リターンアドレスがぶっ壊れてSegmentation Fault します。10行目のprintfを有効にするとguard1, guard2がスタックに配置されて、受け止めてくれるので、80回でも耐えます。

難解なC言語仕様、曖昧な利用者の理解、過激なコンパイラの最適化、が招く結末

バッファオーバーランを期待していた向きには残念（？）かもしれませんが、guard1, guard2はメモリ上に置いても置かなくても、C言語仕様に矛盾しないなら、どっちでも良いです。もっというとC言語仕様に矛盾しないなら、コンパイラの最適化は何をやってもOK です。

この「C言語仕様に矛盾しないなら」はおそらくコンパイラ開発者には常識なのでしょうけども、C言語の仕様は人間に優しくないのと、大多数のC言語プログラマは言語仕様（特に未定義動作）を理解しておらず、何となく使っています。

難解な仕様、曖昧な理解、過激な最適化の相乗効果により、今日も世界のどこかで
「最適化で動きが変になっちゃったよ……。どうして…どうして……？」
とコンパイラとすれ違ったプログラマが泣いているでしょう。。。

参考

大したものではありませんが、ソースコードを載せておきます。

#include <stdio.h>
#include <string.h>

int undefined()
{
	int guard1[50];
	int array[50];
	int guard2[50];
	int sum = 0, i;

	memset(guard1, 0, sizeof(guard1));
	memset(guard2, 0, sizeof(guard2));
	//printf("%p %p %p\n", &guard1[0], &array[0], &guard2[0]);

	for (i = 0; i < 60; i++) {
		array[i] = i;
	}

	for (i = 0; i < 60; i++) {
		sum += array[i];
	}

	for (i = 0; i < 50; i++) {
		printf("%2d: %d %d %d\n", i, guard1[i], array[i], guard2[i]);
	}

	return sum;
}

int main(int argc, char *argv[])
{
	int sum1 = 0, sum2 = 0, i;

	sum1 = undefined();

	for (i = 0; i < 60; i++) {
		sum2 += i;
	}

	printf("%d: %d\n", sum1, sum2);

	return 0;
}

glibcのmemsetは強かった

目次: ベンチマーク

先日（2020年1月12日の日記参照）の続きです。

あまりにもglibcフルアセンブラ版memsetの実装が速くて勝てないので、観念して実装を見たのですが、序盤（1バイト〜32バイト）が弱い理由と、以降（33バイト〜）で勝てない理由がわかりました。

他の実装と違ってglibcはサイズの大きい方から条件を見ています。どうしても条件分岐命令を通る回数が増えるため、序盤に弱いです。

中盤は96バイトまではNEON store x 4と分岐で捌いていて、ループを使いません。分岐もcmpしてbranchではなく、ビットセットされていたら分岐する命令（tbz, tbnz）を使っています（※）。

つまり私が書いたmemsetはループで処理している時点で、ほぼ勝ち目がなかったということです。

グラフでは63バイトまでしか測っていなかったから気づかなかったのですが、ループの2週目に入る65バイトから、さらにボロ負けです。いやはや、これは勝てないですね……。

（※）cmp, branchの2命令をtbz 1命令にする辺り、AArch64アセンブラならではの実装に見えますが、実はCでもif (a & 0x10) とか書くとコンパイラがtbz命令を使います。コンパイラ侮りがたし。

glibcのmemsetのクセ

目次: ベンチマーク

先日memsetを書いていたとき（2020年1月12日の日記参照）に気づいたのですが、glibcのフルアセンブラ版memsetの性能が2通り（遅い、速い）あることに気づきました。だいたい1割くらい性能が変わります。

遅いときと比較すると、自作のmemsetの方が速いですが、速いときと比較するとボロ負けします。割と性能が迫っているためか、影響が大きいです。

何が違うんでしょうね？コードは当然同じですから、違いはmemset関数のロードされるアドレスくらいです。まさかなと思って、スタティックリンクしたら安定して速くなりました。

ダイナミックリンクだと、アプリ側は0xaaaac4fba560で、glibcだけ0xffffbf2dce00のような遠いアドレスに飛ばされます。ベンチマーク中は、アプリのコード ←→ glibcのコードを頻繁に行き来することになるので、TLBミスヒットの影響が出ているんですかね……？？

真因はわかりませんが、アドレスが関係している可能性は高いです。今後、似たようなことをやるときは、スタティックリンクで測った方が良さそうです。

バイトをコピーするSIMD命令

目次: ベンチマーク

最近、見かけるSIMD命令セット（AVXもNEONも）には、レジスタ下位 [7:0] の1バイトを、レジスタ上位 ... [31:24] [23:16] [15:8] の各バイトに配る命令が用意されています。

• AVX: vpbroadcastb
• NEON: dup

この命令はどういう需要があるんだろうか……？memsetの実装では超役に立ちましたが、他の使い道が良くわかりません。

Facebookで上記の話をしていたところ、

• 8bit行列演算: 8bit行列演算ってそんな頻出かな、って思ったら、画像使えば8bitなので十分有り得そう。
• バイト暗号: ブロック毎に空間変換する時とか雑に言えばスカラとベクトルの演算。

と教えてもらいました。なるほど、スカラベクトル積のスカラ側を配るときに便利ですね。

SIMD命令のない世界

ちなみにSIMDのない処理系はどうしているのか見てみると、

int a = (何かの数字);

としたときに、

a &= 0xff;
a *= 0x01010101;

のようにand, mov, mulを使っていました。もちろん、

a &= 0xff;
a |= a << 8;
a |= a << 16;

のようにand, shift, or, shift, orでもできますが、今日日のプロセッサだと整数乗算の方が速そうですね。