コグノスケ

VSCode を使って Windows から Linux アプリのデバッグ その 1

その 1、その 2

同じことをしている人があまり居なさそうだったので、メモしておきます。

きっかけは GCC のコードを GDB の CUI モードで追っていて辛くなったことです。GCC のコードは超ぐちゃぐちゃの悲惨なコードで非常に追いづらく、GDB をもってしても何が起きているのか把握するのは困難です。せめてデバッガの画面くらいは GUI にして、見やすくできないか、と考えました。

Windows から Linux アプリのデバッグ、それぞれの役割

想定する構成は上記のとおりで、Linux 側には GUI がなく（ディスプレイを繋いでいない、など）、Windows 側はデバッグのみで、Linux 側でその他の全て（ビルドなど）を行う想定です。

Linux 側の準備

この記事を読んでいるということは、既に何かデバッグしたいアプリケーションがあると思いますから、基本的なツールである gcc や make などのインストールは省略させてもらいます。gdbserver をインストールするだけで良いはずです。

# apt-get install gdbserver

Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  gdbserver
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/458 kB of archives.
After this operation, 1165 kB of additional disk space will be used.
Selecting previously unselected package gdbserver.
(Reading database ... 99167 files and directories currently installed.)
Preparing to unpack .../gdbserver_8.2.1-2+b3_amd64.deb ...
Unpacking gdbserver (8.2.1-2+b3) ...
Setting up gdbserver (8.2.1-2+b3) ...

デバッグするプログラムは何でも良いですが、下記を使用します。渡した引数を表示するだけのプログラムです。

#include <stdio.h>

int main(int argc, char *argv[])
{
	printf("argc: %d\n", argc);

	for (int i = 0; i < argc; i++) {
		printf("argv[%d]: %s\n", i, argv[i]);
	}

	return 0;
}

$ gcc -Wall -g -O0 a.c

$ ./a.out a b c

argc: 4
argv[1]: a
argv[2]: b
argv[3]: c

まずは普通に CUI から GDB で追ってみます。図示するとこのような構成です。

GDB で Linux アプリのデバッグ

あえてやる必要もなさそうですけど、このあとの一貫性のために試します。

$ gdb a.out

...
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a.out...

(gdb) b main

Breakpoint 1 at 0x1144: file a.c, line 5.

(gdb) r a b c d

Starting program: /home/katsuhiro/share/falcon/projects/c/test_argv/a.out a b c d

Breakpoint 1, main (argc=5, argv=0x7fffffffdca8) at a.c:5
5               printf("argc: %d\n", argc);

(gdb) c

Continuing.
argc: 5
argv[1]: a
argv[2]: b
argv[3]: c
argv[4]: d
[Inferior 1 (process 4008866) exited normally]

普通です。次は gdbserver と連携させリモートで GDB で追ってみます。図示するとこのような構成です。

gdbserver + GDB で Linux アプリのデバッグ

実際にやってみましょう。ターミナルを 2つ用意してください。

★★ターミナル 1つ目

$ gdbserver --multi localhost:1234 ./a.out a b c d

Process ./a.out created; pid = 4008908
Listening on port 1234
Remote debugging from host ::1, port 32918

★ main で break したあとの continue を実行すると下記が出力される

argc: 5
argv[1]: a
argv[2]: b
argv[3]: c
argv[4]: d
 
Child exited with status 0


★★ターミナル 2つ目

$ gdb

...
For help, type "help".
Type "apropos word" to search for commands related to "word".

(gdb) target remote :1234

Remote debugging using :1234
Reading test_argv/a.out from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading test_argv/a.out from remote target...
Reading symbols from target:test_argv/a.out...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/5b/e47e85c990f390b0dccb6ca9dc3e70f410dc6a.debug...
0x00007ffff7fd3090 in _start () from target:/lib64/ld-linux-x86-64.so.2

(gdb) b main

Breakpoint 1 at 0x555555555144: file a.c, line 5.

(gdb) c

Continuing.
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...

Breakpoint 1, main (argc=5, argv=0x7fffffffdd18) at a.c:5
5               printf("argc: %d\n", argc);

(gdb) l

1       #include <stdio.h>
2
3       int main(int argc, char *argv[])
4       {
5               printf("argc: %d\n", argc);
6
7               for (int i = 1; i < argc; i++) {
8                       printf("argv[%d]: %s\n", i, argv[i]);
9               }
10

(gdb) c

Continuing.
[Inferior 1 (process 4008908) exited normally]

ブレークもできますし、ソースコードも表示されます。良い感じですね。

使い勝手は GDB 単体でデバッグするときとほぼ同じですが、1点だけ注意があります。デバッガとして動作するのは gdbserver であり、プログラムの printf などの標準出力は、gdbserver を動かしているターミナル側に出ることに注意してください。この使い方における GDB は gdbserver と通信するだけの役です。

Samba のセットアップについては、ここで解説せずとも、詳しいサイトがたくさんあると思いますので、そちらをご参照ください。

思ったより長くなってきたので、続きは次回に。

VSCode を使って Windows から Linux アプリのデバッグ その 2

その 1、その 2

昨日（2021年 3月 3日の日記参照）の続きです。

GDB の準備

Windows 側で使用する GDB を用意します。最初は MinGW のバイナリが使えるかと思ったのですが、MinGW のバイナリは Windows の実行形式（COFF）のデバッグ用で、Linux の実行形式（ELF）は認識せず、ダメでした。残念。

GDB は binutils に含まれています。ビルド方法を下記に示します。バージョンは何でも良いと思いますが、私は MinGW も使っている 2.32 にしました。

$ git clone git://sourceware.org/git/binutils-gdb.git
$ cd binutils-gdb
$ git checkout -b 2_32 binutils-2_32

$ mkdir build
$ cd build
$ ../configure \
    --host=x86_64-w64-mingw32 \
    --target=x86_64-unknown-linux-gnu \
    --prefix=`pwd`/_install \
    --disable-werror \
    --with-expat=no \
    --enable-sim \
    --enable-libdecnumber \
    --enable-libreadline \
    --enable-gas \
    --enable-binutils \
    --enable-ld \
    --disable-gold \
    --enable-gprof

$ make -j8
$ make install

ビルドが成功すると、build/_install ディレクトリに Windows 用の binutils のバイナリ（GDB も含む）がインストールされます。フォルダごと Windows 側にコピーすれば動きます。ディレクトリの名前 _install は Windows 側に持っていったあとに変更しても構いません。

比較的、新しい環境（Ubuntu 20 など）だと MinGW が何か変らしく、gdb/common/common-defs.h にある _FORTIFY_SOURCE の定義を消さないと、リンクの時に __memcpy_chk() などの関数が見当たらないと言われてエラーになります。

  CXXLD  gdb.exe
/usr/bin/x86_64-w64-mingw32-ld: ada-tasks.o:/usr/share/mingw-w64/include/string.h:202: undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: amd64-tdep.o:/usr/share/mingw-w64/include/string.h:202: undefined reference to `__memcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: breakpoint.o:/usr/share/mingw-w64/include/string.h:228: undefined reference to `__strcpy_chk'
/usr/bin/x86_64-w64-mingw32-ld: breakpoint.o:/usr/share/mingw-w64/include/string.h:228: undefined reference to `__strcpy_chk'
...

とりあえず下記のパッチでエラーは回避できますが、おそらく正しい直し方ではありません。原因は調べていません。もしご存知の方は教えていただけると嬉しいです。

diff --git a/gdb/common/common-defs.h b/gdb/common/common-defs.h
index e574de5ed66..a9b0520b4c5 100644
--- a/gdb/common/common-defs.h
+++ b/gdb/common/common-defs.h
@@ -69,7 +69,7 @@
    then we don't do anything.  */

 #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0
-#define _FORTIFY_SOURCE 2
+//#define _FORTIFY_SOURCE 2
 #endif

 #include <stdarg.h>

面倒であれば、ビルド済みのバイナリ（ binutils_x86_64-unknown-linux-gnu.zip）をどこか適当なディレクトリに展開してもらえれば動くはずです。Windows 10 で動作確認しています。

Windows 側の準備

Visual Studio Code をインストールします。Microsoft のサイトからダウンロードできます（Visual Studio Code - Code Editing. Redefined）。

はじめに C/C++ Extension をインストールします。GDB と連携するためです。

VSCode C/C++ Extension のインストール画面

先ほどのテストプログラムが置いてあるディレクトリを開きます。メニューの [File] - [Open Folder] です。ここでは Z:\projects\c\test_argv にあるとします。

左側のタブから Run and Debug を選択します。Ctrl + Shift + D でも良いです。次に青い Run and Debug ボタンを押します。すると Select Environment というコンボボックスが出てくるので C++ (GDB/LLDB) を選択します。

Run and Debug

C/C++ (GDB/LLDB) を選択

ソースコードペインに launch.json のテンプレートが表示されると思うので、下記の内容に書き換えます。miDebuggerPath や miDebuggerServerAddress は適宜、環境に合わせて書き換えてください。

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Attach",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "cwd": "${workspaceFolder}",
            "MIMode": "gdb",
            "miDebuggerPath": "c:\app\binutils\bin\x86_64-unknown-linux-gnu-gdb.exe",
            "miDebuggerServerAddress": "192.168.1.2:1234",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true,
                },
                {
                    "description": "Relace absolute path of source code",
                    "ignoreFailures": false,
                    "text": "set substitute-path /home/katsuhiro/share/falcon z:/",
                },
            ],
        },
    ]
}

ここで大事なのは setupCommands の set substitute-path です。gdb は Linux 側の絶対パスでソースコードの場所を通知してくることがあります。Linux 側の絶対パスを渡されても Windows 側ではファイルを探せませんから、絶対パスの一部を Windows 側に存在するパスに置き換えることで、VSCode がソースコードを見つけられるように設定してあげないと、こんなエラーで怒られます。

ソースコードの場所の設定に失敗しているとエラーが出る

今回の例では、

• Linux から見たテストプログラムのある場所: /home/katsuhiro/share/falcon/projects/c/test_argv
• Linux から Samba で Windows に見せている場所: /home/katsuhiro/share/falcon
• Windows のリモートドライブレター: Z:
• Windows から見たテストプログラムのある場所: Z:/projects/c/test_argv

このような設定にしていますから、Windows 側のネットワークドライブ Z:/ が、Linux 側の /home/katsuhiro/share/falcon を指していることを伝えるために、上記の例のように "set substitute-path /home/katsuhiro/share/falcon z:/" にします。もし対応がわからない場合は Samba の設定を確認しましょう。

いざデバッグ

いよいよ最終目的である Linux 側の gdbserver と、Windows 側の VSCode + GDB を連携させます。図示するとこのような構成です。

Windows から Linux アプリのデバッグ、それぞれの役割（再掲）

実際にやってみましょう。最初に Linux 側で gdbserver を起動します。

$ gdbserver --multi localhost:1234 ./a.out a b c d

Process ./a.out created; pid = 15409
Listening on port 1234
Remote debugging from host ::ffff:192.168.1.112, port 64957

★ main で break したあと continue すると下記が出力される

argc: 5
argv[1]: aa
argv[2]: bb
argv[3]: cc
argv[4]: dd
 
Child exited with status 0

その後、VSCode で main にブレークポイントを設定します。F5 キーを押してデバッグ開始すると、main() 関数で停止し、ソースコードが表示されるはずです。

Windows 側からデバッグできている状態

うまくいきました、良かった良かった。

繋がらないときは

Unable to start debugging. Unexpected GDB output from command... のように言われて、デバッグできない場合は、

• miDebuggerPath の場所に x86_64-unknown-linux-gnu-gdb.exe はあるか？
• miDebuggerPath に指定したファイルはコマンドプロンプトなどから実行可能か？
• miDebuggerServerAddress は正しいか？
• gdbserver を起動し忘れていないか？
• Windows 用の GDB から target remote [miDebuggerServerAddress に指定したアドレス] としたとき繋がるか？

上記を今一度チェックしてみてください。特に gdbserver はデバッグの度に毎回起動しなければなりません。割と忘れがちです。これ非常に面倒なので、改善方法が既にありそうな気がします（今はわかりません）。

Windows 要らなくない？

そこに気づかれましたか、鋭いですね、おっしゃる通りです。私も binutils をビルドし終わった辺りで、もしや VSCode を Linux 側で動かせば何の苦労もなかったのでは？と気づきましたが、遅すぎたのでここまで突っ走りました。正直、Windows を使うだけ面倒で、何も利点がないです。なるほど、この方法を実践している人が誰もいないわけです。

Windows からデバッグだけする方法が向いている人、環境ですか……？うーん、ほとんど居ないと思いますが、強いていえば Linux PC の GUI 環境を整備しておらず、整備も面倒と思っていて、普段遣いの Windows PC しか持っていないような方でしょうか。この手順も大概面倒くさいけどね。

気に入るマウスはどれ？

手に合うワイヤレスマウスを探し続け、高級製品、小さい製品、お手ごろ製品と買いまくり、一時は家に 5個くらいワイヤレスマウスがありました。

日記から遍歴を辿ってみたところ、少なくとも下記の製品を持っていたようです。

• 2004年 12月: Logitech Optical Mouse USB M-UV96
• 2007年 1月: Logicool Nano Cordless Laser Mouse V450
• 2010年 2月: Logicool Cordless Laser Mouse MX1100
• 2011年 12月: Logicool Wireless Mouse M510
• 2012年 4月: Logicool Perfomance MX M950
• 2013年 10月: Microsoft Wireless Mouse 1000
• 2014年 8月: Logicool Perfomance MX M950（2個目）
• 2017年 5月: エレコム EX-G Ultimate Laser Mouse M-XGL20DLBK
• 2017年 5月: Logicool Wireless Mouse M560
• 2017年 12月: Logicool Marathon Mouse M705
• 2021年 1月: Microsoft Basic Optical Mouse

全部で 11個です。こんなに買っていたとは思いませんでした……。

最終的に辿り着いた先は

色々試して最終的に辿り着いたのは、Microsoft の 1000円の有線マウス（Basic Optical Mouse）でした。このマウスは中身がほぼ空っぽでめちゃくちゃ軽いです。

はい、何ですか？ワイヤレスじゃないって？そうですね。ワイヤレスマウスはどうしても重くて、手首が疲れてしまいダメでした。

小さいワイヤレスマウスなら軽いですが、手の大きさと合わずやっぱり手が疲れてしまいます。どうもマウスの持ち方（親指と小指で挟むように持つ）が、小さいマウス、ワイヤレスマウスと合わないみたいです。

という訳でワイヤレスマウスは諦めました。有線マウスは安くて軽くて最高です！

メモ: 技術系の話は Facebook から転記しておくことにした。マウス遍歴を追加。

電源タップの雷ガード

在宅勤務環境を整えようと、電源タップを物色していました。電源タップを見ていると大体 3つに分類できて、

• 普通のタップ
• スイッチ付き
• 雷ガード（雷サージ保護）付き

前者 2つはわかりやすいです。3つ目の雷ガードとは何者でしょう？前から不思議だったので、軽く調べました。

雷ガードの定義

雷ガードは雷の直撃を防ぐわけではなく（それは避雷針の仕事）、落雷したとき電線に混入する 1〜20kV 程度のサージ電流を防ぐ仕組みのようです。パナソニックのタップは 0.8kV, 1.2kV、LED 照明器具は 15kV、サンワサプライは 15kV, 20kV を最大電圧とした製品を見つけました。

• 「雷サージ保護」の定義 - サンワサプライ
• 雷ガード（雷サージ吸収素子 X3）TAP-SP302BK - サンワサプライ
• パナソニック耐雷サージ性能 | 安心品質実験レポート | パナソニック
• 「雷サージ」を防ぐタップを販売しているか、教えてください。 - タップ・延長コード - パナソニック

保護の仕組みですが、サンワサプライは電源系にはバリスタ（Varistor, Variable Resistor）を使っていると書いています。パナソニックのサイトも雷サージ対策にバリスタとあるので、バリスタがポピュラーな仕組みなのでしょう。

参考: 【EMC 対策】雷サージ対策部品 "バリスタ" の落とし穴 - パナソニック

バリスタはいわゆる静電気（ESD, Electric Static Discharge）対策で使われる素子です。ツェナーダイオードを 2つ逆接続したような V-I 特性で、電圧の正負を気にせず、とにかく高い電圧に対し低い抵抗値を持ちます。

参考: チップバリスタ - 電子デバイス・産業用機器 - パナソニック

バリスタと本体の電子機器を並列に接続します。回路に高い電圧が掛かると、バリスタ側の抵抗値が急激に下がり、バリスタ側に電流が流れます。バリスタ側に電流が逃げることで、本体の電子機器は高い電圧を食らわずに済みサージ電流から保護される仕組みです。

ESD の場合は素子が壊れないように十分な耐圧のバリスタを選定すると思いますが、雷サージの電圧は最大何 V かわかりません。時にバリスタが耐えられない電圧が掛かり、バリスタが故障します。特にバリスタがショートモードで故障し、ユーザーが気づかずに使い続けた場合、素子が加熱し火災が発生する恐れがあります。

これは実際に起きた事故で、10年前に NOATEK の雷ガード製品がバリスタの加熱＆火災を起こし 150万個もリコールされました。NITE の解説を見る限り、この製品は「雷ガード＝バリスタ入れれば OK」という甘い設計だったため、ショートモードで故障した後、加熱を検知できず火災に至ったようです。

• NITE（製品評価技術基盤機構）の解説
• 経済産業省: リコール情報

雷を防いだら、火事になりました、なんて製品は全く笑えません。安全な設計というのは難しいですね。

こんなことばかり調べているから、全然買い物が進みません。在宅勤務環境が整うのはまだ先のようです……。

メモ: 技術系の話は Facebook から転記しておくことにした。リンク、情報追加、加筆。

浮動小数点数の丸め方

目次: C 言語と libc - まとめリンク

C 言語の規格では浮動小数点の丸めモードが 4つ定義されています。実行中に変更することができ、fesetround() 関数で指定します。

つい UPWARD = 切り上げ、DOWNWARD = 切り捨て、と説明したくなりますが、TOWARDZERO と区別が付きませんし、正の数はまだしも、負の数を考えたとき混乱します。やや意味はわかりにくいですが、誤解のない説明をすると、こんな感じです。

FE_DOWNWARD

マイナス無限大方向への丸め、-11.5, -10.5, 10.5, 11.5 を整数にすると、-12, -11, 10, 11

FE_TONEAREST

最も近い数への丸め

FE_TOWARDZERO

ゼロ方向への丸め、-11.5, -10.5, 10.5, 11.5 を整数にすると、-11, -10, 10, 11

FE_UPWARD

プラス無限大方向への丸め、-11.5, -10.5, 10.5, 11.5 を整数にすると、-11, -10, 11, 12

DOWNWARD, TOWARDZERO, UPWARD は他に解釈の余地がありませんが、TONEAREST はど真ん中の数が来たときに、扱いに困ります。IEEE 754 では 2つの方式が定義されているようです。

ties to even

偶数方向に丸める、10.5, 11.5 を整数にすると 10.0, 12.0 になる

ties away from zero

ゼロから遠い方に丸める、10.5, 11.5 を整数にすると 11.0, 12.0 になる、四捨五入に近い

説明するより実際に動かしたほうがわかりやすいでしょう。

丸めモードを実感

丸めモードの動作を確認するプログラムを書きます。8388610 という数値は float の仮数部 24bit を使い切った値となっています。1.0 の増減は表現できますが、1.0 より小さい値の増減はビットが足りないので表せないです。

8388610 に対し 1.0 より小さい値（今回は 0.25, 0.5, 0.75 の 3つを選びました）を加減算すれば、結果を正確に表現できないので、必ず丸め処理が行われます。丸めモードによる演算結果の違いを見るには丁度よいですね。

#include <stdio.h>
#include <fenv.h>
#include <float.h>

#define BASE_EVEN    8388610.0
#define BASE_ODD     8388611.0

union n_f {
	int n;
	float f;
};

static inline void test(void)
{
	union n_f a, b, c;

	a.f = BASE_EVEN;
	b.f = 0.25;
	c.f = a.f + b.f;
	printf("   %.2f+%.2f =  %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.5;
	c.f = a.f + b.f;
	printf("   %.2f+%.2f =  %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.75;
	c.f = a.f + b.f;
	printf("   %.2f+%.2f =  %.2f 0x%08x\n", a.f, b.f, c.f, c.n);

	a.f = BASE_ODD;
	b.f = 0.25;
	c.f = a.f + b.f;
	printf("   %.2f+%.2f =  %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.5;
	c.f = a.f + b.f;
	printf("   %.2f+%.2f =  %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.75;
	c.f = a.f + b.f;
	printf("   %.2f+%.2f =  %.2f 0x%08x\n", a.f, b.f, c.f, c.n);

	a.f = -BASE_EVEN;
	b.f = 0.25;
	c.f = a.f - b.f;
	printf("  %.2f-%.2f = %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.5;
	c.f = a.f - b.f;
	printf("  %.2f-%.2f = %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.75;
	c.f = a.f - b.f;
	printf("  %.2f-%.2f = %.2f 0x%08x\n", a.f, b.f, c.f, c.n);

	a.f = -BASE_ODD;
	b.f = 0.25;
	c.f = a.f - b.f;
	printf("  %.2f-%.2f = %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.5;
	c.f = a.f - b.f;
	printf("  %.2f-%.2f = %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
	b.f = 0.75;
	c.f = a.f - b.f;
	printf("  %.2f-%.2f = %.2f 0x%08x\n", a.f, b.f, c.f, c.n);
}

int main(int argc, char *argv[])
{
	printf("DOWNWARD\n");
	fesetround(FE_DOWNWARD);
	test();

	printf("TONEAREST\n");
	fesetround(FE_TONEAREST);
	test();

	printf("TOWARDZERO\n");
	fesetround(FE_TOWARDZERO);
	test();

	printf("UPWARD\n");
	fesetround(FE_UPWARD);
	test();

	return 0;
}

ところが、コンパイルして実行すると奇妙な結果が得られます。全て TONEAREST と同じ結果になってしまいます。

$ gcc -Wall -g -O2 a.c -lm

$ ./a.out

DOWNWARD
   8388610.00+0.25 =  8388610.00 0x4b000002    ★TONEAREST と同じになっている
   8388610.00+0.50 =  8388610.00 0x4b000002
   8388610.00+0.75 =  8388611.00 0x4b000003
   8388611.00+0.25 =  8388611.00 0x4b000003
   8388611.00+0.50 =  8388612.00 0x4b000004
   8388611.00+0.75 =  8388612.00 0x4b000004
  -8388610.00-0.25 = -8388610.00 0xcb000002
  -8388610.00-0.50 = -8388610.00 0xcb000002
  -8388610.00-0.75 = -8388611.00 0xcb000003
  -8388611.00-0.25 = -8388611.00 0xcb000003
  -8388611.00-0.50 = -8388612.00 0xcb000004
  -8388611.00-0.75 = -8388612.00 0xcb000004
TONEAREST
   8388610.00+0.25 =  8388610.00 0x4b000002
   8388610.00+0.50 =  8388610.00 0x4b000002
   8388610.00+0.75 =  8388611.00 0x4b000003
   8388611.00+0.25 =  8388611.00 0x4b000003
   8388611.00+0.50 =  8388612.00 0x4b000004
   8388611.00+0.75 =  8388612.00 0x4b000004
  -8388610.00-0.25 = -8388610.00 0xcb000002
  -8388610.00-0.50 = -8388610.00 0xcb000002
  -8388610.00-0.75 = -8388611.00 0xcb000003
  -8388611.00-0.25 = -8388611.00 0xcb000003
  -8388611.00-0.50 = -8388612.00 0xcb000004
  -8388611.00-0.75 = -8388612.00 0xcb000004
TOWARDZERO
   8388610.00+0.25 =  8388610.00 0x4b000002    ★TONEAREST と同じになっている
   8388610.00+0.50 =  8388610.00 0x4b000002
   8388610.00+0.75 =  8388611.00 0x4b000003
   8388611.00+0.25 =  8388611.00 0x4b000003
   8388611.00+0.50 =  8388612.00 0x4b000004
   8388611.00+0.75 =  8388612.00 0x4b000004
  -8388610.00-0.25 = -8388610.00 0xcb000002
  -8388610.00-0.50 = -8388610.00 0xcb000002
  -8388610.00-0.75 = -8388611.00 0xcb000003
  -8388611.00-0.25 = -8388611.00 0xcb000003
  -8388611.00-0.50 = -8388612.00 0xcb000004
  -8388611.00-0.75 = -8388612.00 0xcb000004
UPWARD
   8388610.00+0.25 =  8388610.00 0x4b000002    ★TONEAREST と同じになっている
   8388610.00+0.50 =  8388610.00 0x4b000002
   8388610.00+0.75 =  8388611.00 0x4b000003
   8388611.00+0.25 =  8388611.00 0x4b000003
   8388611.00+0.50 =  8388612.00 0x4b000004
   8388611.00+0.75 =  8388612.00 0x4b000004
  -8388610.00-0.25 = -8388610.00 0xcb000002
  -8388610.00-0.50 = -8388610.00 0xcb000002
  -8388610.00-0.75 = -8388611.00 0xcb000003
  -8388611.00-0.25 = -8388611.00 0xcb000003
  -8388611.00-0.50 = -8388612.00 0xcb000004
  -8388611.00-0.75 = -8388612.00 0xcb000004

これは GCC の最適化による影響です。O1 以上の最適化を行うと、演算時の丸めモードを TONEAREST と仮定し、コンパイル時に計算できる値を事前に計算する、という最適化が行われます。

この最適化が都合が良い場合もありますが、今回のようなプログラムでは丸めモードを TONEAREST 以外に変更しているので、勝手に TONEAREST を仮定してはいけません。GCC の場合 -frounding-math というオプションを付けると、デフォルトの丸めモードを仮定した最適化をやめることができます。

$ gcc -Wall -g -O2 a.c -lm -frounding-math

$ ./a.out

DOWNWARD    ★マイナス無限大方向に丸める
   8388610.00+0.25 =  8388610.00 0x4b000002    ★ 10.25 ->  10.00
   8388610.00+0.50 =  8388610.00 0x4b000002    ★ 10.50 ->  10.00
   8388610.00+0.75 =  8388610.00 0x4b000002    ★ 10.75 ->  10.00
   8388611.00+0.25 =  8388611.00 0x4b000003    ★ 11.25 ->  11.00
   8388611.00+0.50 =  8388611.00 0x4b000003    ★ 11.50 ->  11.00
   8388611.00+0.75 =  8388611.00 0x4b000003    ★ 11.75 ->  11.00
  -8388610.00-0.25 = -8388611.00 0xcb000003    ★-10.25 -> -11.00
  -8388610.00-0.50 = -8388611.00 0xcb000003    ★-10.50 -> -11.00
  -8388610.00-0.75 = -8388611.00 0xcb000003    ★-10.75 -> -11.00
  -8388611.00-0.25 = -8388612.00 0xcb000004    ★-11.25 -> -12.00
  -8388611.00-0.50 = -8388612.00 0xcb000004    ★-11.50 -> -12.00
  -8388611.00-0.75 = -8388612.00 0xcb000004    ★-11.75 -> -12.00
TONEAREST    ★最近接数に丸める、真ん中（0.5）は偶数側に丸める
   8388610.00+0.25 =  8388610.00 0x4b000002    ★ 10.25 ->  10.00
   8388610.00+0.50 =  8388610.00 0x4b000002    ★ 10.50 ->  10.00
   8388610.00+0.75 =  8388611.00 0x4b000003    ★ 10.75 ->  11.00
   8388611.00+0.25 =  8388611.00 0x4b000003    ★ 11.25 ->  11.00
   8388611.00+0.50 =  8388612.00 0x4b000004    ★ 11.50 ->  12.00
   8388611.00+0.75 =  8388612.00 0x4b000004    ★ 11.75 ->  12.00
  -8388610.00-0.25 = -8388610.00 0xcb000002    ★-10.25 -> -10.00
  -8388610.00-0.50 = -8388610.00 0xcb000002    ★-10.50 -> -10.00
  -8388610.00-0.75 = -8388611.00 0xcb000003    ★-10.75 -> -11.00
  -8388611.00-0.25 = -8388611.00 0xcb000003    ★-11.25 -> -11.00
  -8388611.00-0.50 = -8388612.00 0xcb000004    ★-11.50 -> -12.00
  -8388611.00-0.75 = -8388612.00 0xcb000004    ★-11.75 -> -12.00
TOWARDZERO    ★ゼロ方向に丸める
   8388610.00+0.25 =  8388610.00 0x4b000002    ★ 10.25 ->  10.00
   8388610.00+0.50 =  8388610.00 0x4b000002    ★ 10.50 ->  10.00
   8388610.00+0.75 =  8388610.00 0x4b000002    ★ 10.75 ->  10.00
   8388611.00+0.25 =  8388611.00 0x4b000003    ★ 11.25 ->  11.00
   8388611.00+0.50 =  8388611.00 0x4b000003    ★ 11.50 ->  11.00
   8388611.00+0.75 =  8388611.00 0x4b000003    ★ 11.75 ->  11.00
  -8388610.00-0.25 = -8388610.00 0xcb000002    ★-10.25 -> -10.00
  -8388610.00-0.50 = -8388610.00 0xcb000002    ★-10.50 -> -10.00
  -8388610.00-0.75 = -8388610.00 0xcb000002    ★-10.75 -> -10.00
  -8388611.00-0.25 = -8388611.00 0xcb000003    ★-11.25 -> -11.00
  -8388611.00-0.50 = -8388611.00 0xcb000003    ★-11.50 -> -11.00
  -8388611.00-0.75 = -8388611.00 0xcb000003    ★-11.75 -> -11.00
UPWARD    ★プラス無限大方向に丸める
   8388610.00+0.25 =  8388611.00 0x4b000003    ★ 10.25 ->  11.00
   8388610.00+0.50 =  8388611.00 0x4b000003    ★ 10.50 ->  11.00
   8388610.00+0.75 =  8388611.00 0x4b000003    ★ 10.75 ->  11.00
   8388611.00+0.25 =  8388612.00 0x4b000004    ★ 11.25 ->  12.00
   8388611.00+0.50 =  8388612.00 0x4b000004    ★ 11.50 ->  12.00
   8388611.00+0.75 =  8388612.00 0x4b000004    ★ 11.75 ->  12.00
  -8388610.00-0.25 = -8388610.00 0xcb000002    ★-10.25 -> -10.00
  -8388610.00-0.50 = -8388610.00 0xcb000002    ★-10.50 -> -10.00
  -8388610.00-0.75 = -8388610.00 0xcb000002    ★-10.75 -> -10.00
  -8388611.00-0.25 = -8388611.00 0xcb000003    ★-11.25 -> -11.00
  -8388611.00-0.50 = -8388611.00 0xcb000003    ★-11.50 -> -11.00
  -8388611.00-0.75 = -8388611.00 0xcb000003    ★-11.75 -> -11.00

丸めモードの切り替えが正常に働いている様子がわかります。また TONEAREST の丸めモードにした場合、ties to even であることも観察できます。

C 言語の規格は何と言っている？

C99 の final draft をざっと見た限りでは、ties to even か ties away from zero か、明確に書かれていないように見えました。規格的にはどちらなんでしょうね？実装依存なのかなあ？

GCC を調べる - memmove の folding その 1

目次: GCC を調べる - まとめリンク

GCC の memmove に対する最適化とバグっぽい挙動についてのメモです。半年経ったら絶対忘れてわからなくなる自信があるので、書き残しておきます。

検証に使用するのは下記のプログラムです。"AB0123456789abcdefg" が格納された配列 s から、同じ配列 s に 2文字だけずらして memmove() します。期待値は先頭 2文字が消えた "0123456789abcdefg" です。このプログラムは memmove() を使う必要があります。memcpy() はコピー元（src）とコピー先（dst）が重複したメモリ領域だと正常に動作しないことがあるからです。

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

#define PRE "AB"
#define STR "0123456789abcdefg"
#define NOP __asm__ volatile("nop;")

int main(int argc, char *argv[])
{
	volatile char s[] = PRE STR;
	char *p = (char *)s;
	size_t sz_pre = strlen(PRE);
	size_t sz = strlen(p) - sz_pre + 1;

	NOP;
	memmove(p, p + sz_pre, sz);
	NOP; NOP;

	if (strcmp(p, STR) == 0) {
		printf("  OK: %s\n", p);
	} else {
		printf("  NG: %s\n", p);
	}
}

$ gcc -O2 -Wall -g test.c

$ ./a.out
  NG: 01234567abcdefg

しかし、実行してみると期待値と一致しません。真ん中の "89" がどこかに消えました。また配列 s の宣言から volatile を削除すると、正常に動作するようになります。一体、何が起きているのでしょうか？

GCC のアグレッシブな最適化

GCC はある条件下で memmove() を __builtin_memcpy() に置き換えるという最適化を行います。その様子を観察するために、オプション --dump-tree-all を付けて、GIMPLE のファイルを出力します。

$ gcc -O2 -Wall -g test.c --dump-tree-all

$ grep -r 'memmove ' ./ | sort

./test.c.004t.original:  memmove ((void *) p, (const void *) (p + (sizetype) sz_pre), sz);
./test.c.005t.gimple:    memmove (p, _3, sz);
./test.c.007t.omplower:    memmove (p, _3, sz);
./test.c.008t.lower:  memmove (p, _3, sz);
./test.c.011t.eh:  memmove (p, _3, sz);
./test.c.013t.cfg:  memmove (p, _3, sz);
./test.c.015t.ompexp:  memmove (p, _3, sz);
./test.c.020t.fixup_cfg1:  memmove (p, _3, sz);
./test.c.021t.ssa:  memmove (p_8, _3, sz_10);
./test.c.023t.nothrow:  memmove (p_8, _3, sz_10);
./test.c.025t.fixup_cfg2:  memmove (p_8, _3, sz_10);
./test.c.026t.local-fnsummary1:  memmove (p_8, _3, sz_10);
./test.c.027t.einline:  memmove (p_8, _3, sz_10);
./test.c.028t.early_optimizations:  memmove (p_8, _3, sz_10);
./test.c.029t.objsz1:  memmove (p_8, _3, sz_10);

ファイルを memmove で検索すると、029t.objsz1 を最後に出現しなくなっています。029t.objsz1 の次である 030t.cpp1 を見て、memmove がどうなったのか確かめます。

// test.c.030t.ccp1

;; Function main (main, funcdef_no=11, decl_uid=2555, cgraph_uid=12, symbol_order=11)

main (int argc, char * * argv)
{

...

  __asm__ __volatile__("nop;");
  # DEBUG BEGIN_STMT
  __builtin_memcpy (&s, &MEM <volatile char[20]> [(void *)&s + 2B], sz_10);
  # DEBUG BEGIN_STMT
  __asm__ __volatile__("nop;");
  # DEBUG BEGIN_STMT
  __asm__ __volatile__("nop;");

...

検証用プログラムでは memmove と書いたはずの場所が、__builtin_memcpy() に変わっています。この __builtin_memcpy() は最終的にアセンブラに展開されます。あまり詳しく追っていませんが、末尾の余りバイトをコピーしてから、先頭から 8バイトずつコピーするループが実行されるようで、src と dest が重なっていると、正常に動作しません。

$ objdump -drS a.out

...

        NOP;
    1084:       90                      nop
        size_t sz = strlen(p) - sz_pre + 1;
    1085:       48 8d 50 ff             lea    -0x1(%rax),%rdx
        memmove(p, p + sz_pre, sz);
    1089:       48 8d 4c 24 02          lea    0x2(%rsp),%rcx
    108e:       48 83 fa 08             cmp    $0x8,%rdx
    1092:       73 52                   jae    10e6 <main+0x86>    ★コピーするコードの本体
    1094:       f6 c2 04                test   $0x4,%dl
    1097:       0f 85 85 00 00 00       jne    1122 <main+0xc2>
    109d:       48 85 d2                test   %rdx,%rdx
    10a0:       74 0f                   je     10b1 <main+0x51>
    10a2:       0f b6 01                movzbl (%rcx),%eax
    10a5:       88 45 00                mov    %al,0x0(%rbp)
    10a8:       f6 c2 02                test   $0x2,%dl
    10ab:       0f 85 80 00 00 00       jne    1131 <main+0xd1>
        NOP; NOP;
    10b1:       90                      nop
    10b2:       90                      nop

...

        memmove(p, p + sz_pre, sz);
    10e6:       48 8b 74 14 fa          mov    -0x6(%rsp,%rdx,1),%rsi
    10eb:       48 83 e8 02             sub    $0x2,%rax
    10ef:       48 89 74 14 f8          mov    %rsi,-0x8(%rsp,%rdx,1)
    10f4:       48 83 f8 08             cmp    $0x8,%rax
    10f8:       72 b7                   jb     10b1 <main+0x51>
    10fa:       48 83 e0 f8             and    $0xfffffffffffffff8,%rax
    10fe:       31 d2                   xor    %edx,%edx
    1100:       48 8b 34 11             mov    (%rcx,%rdx,1),%rsi      ★この辺りがコピーのためのループ
    1104:       48 89 74 15 00          mov    %rsi,0x0(%rbp,%rdx,1)
    1109:       48 83 c2 08             add    $0x8,%rdx
    110d:       48 39 c2                cmp    %rax,%rdx
    1110:       72 ee                   jb     1100 <main+0xa0>
    1112:       eb 9d                   jmp    10b1 <main+0x51>
                printf("  OK: %s\n", p);
    1114:       48 8d 3d fb 0e 00 00    lea    0xefb(%rip),%rdi        # 2016 <_IO_stdin_used+0x16>
    111b:       e8 20 ff ff ff          callq  1040 <printf@plt>
    1120:       eb bc                   jmp    10de <main+0x7e>
        memmove(p, p + sz_pre, sz);
    1122:       8b 01                   mov    (%rcx),%eax
    1124:       89 45 00                mov    %eax,0x0(%rbp)
    1127:       8b 44 11 fc             mov    -0x4(%rcx,%rdx,1),%eax
    112b:       89 44 15 fc             mov    %eax,-0x4(%rbp,%rdx,1)
    112f:       eb 80                   jmp    10b1 <main+0x51>
    1131:       0f b7 44 11 fe          movzwl -0x2(%rcx,%rdx,1),%eax
    1136:       66 89 44 15 fe          mov    %ax,-0x2(%rbp,%rdx,1)
    113b:       e9 71 ff ff ff          jmpq   10b1 <main+0x51>

長くなってきたので、また次回。

GCC を調べる - memmove の folding その 2

目次: GCC を調べる - まとめリンク

前回は memmove() が 030t.ccp1 という最適化パスにて __builtin_memcpy() に置き換えられ、誤動作してしまうところまで見ました。今回はどこで置き換えられているのか、追いかけます。

入れ替えを行っている場所は gimple_fold_builtin_memory_op() という関数です。コールスタックは下記のようになります。今回は GCC 11 というか HEAD を使います。関数名は若干違いますが GCC 8 くらいでも大筋は同じです。

do_ssa_ccp()  @tree-ssa-ccp.c
  ccp_finalize()
    substitute_and_fold_engine::substitute_and_fold()  @tree-ssa-propagate.c
      substitute_and_fold_dom_walker walker (CDI_DOMINATORS, this);
      walker.walk (ENTRY_BLOCK_PTR_FOR_FN (cfun));
        dom_walker::walk()  @domwalk.c
          substitute_and_fold_dom_walker::before_dom_children()  @tree-ssa-propagate.c
            fold_stmt()  @gimple-fold.c
              fold_stmt_1()  @gimple-fold.c
                gimple_fold_call()
                  gimple_fold_builtin()
                    gimple_fold_builtin_memory_op()

置き換えている箇所は gimple_fold_builtin_memory_op() 内に 3箇所ありますが、今回のケースに該当するのは下記の部分です。

// gcc/gcc/gimple-fold.c

static bool
gimple_fold_builtin_memory_op (gimple_stmt_iterator *gsi,
			       tree dest, tree src, enum built_in_function code)
{
  gimple *stmt = gsi_stmt (*gsi);
  tree lhs = gimple_call_lhs (stmt);
  tree len = gimple_call_arg (stmt, 2);
  location_t loc = gimple_location (stmt);

...

      if (code == BUILT_IN_MEMMOVE)
	{

...

	  /* If *src and *dest can't overlap, optimize into memcpy as well.  */
	  if (TREE_CODE (src) == ADDR_EXPR
	      && TREE_CODE (dest) == ADDR_EXPR)
	    {

              //...ここでチェックしている...

	      fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
	      if (!fn)
		return false;
	      gimple_call_set_fndecl (stmt, fn);    //★★ここで memmove -> memcpy に置き換わる
	      gimple_call_set_arg (stmt, 0, dest);
	      gimple_call_set_arg (stmt, 1, src);
	      fold_stmt (gsi);
	      return true;
	    }

...

/*
 * 補足: gimple * の中身が見たいときは、下記のようにすると表示できます。
 *
 *   print_gimple_stmt (stdout, stmt, 0);       //HEAD
 *   print_gimple_stmt (stdout, stmt, 0, 0);    //GCC 8 あたり
 */

検証プログラムは memmove() の引数にポインタを渡しているので、TREE_CODE (src) == ADDR_EXPR && TREE_CODE (dest) == ADDR_EXPR の条件が成立します。

置き換えの前にはいくつかチェックがあって、memmove() を memcpy() に置き換えるべきではないと判断したら return false; し、置き換え箇所に到達しない仕組みになっています。

// gcc/gcc/gimple-fold.c

	  /* If *src and *dest can't overlap, optimize into memcpy as well.  */
	  if (TREE_CODE (src) == ADDR_EXPR
	      && TREE_CODE (dest) == ADDR_EXPR)
	    {
	      tree src_base, dest_base, fn;
	      poly_int64 src_offset = 0, dest_offset = 0;
	      poly_uint64 maxsize;

              //★★src->expr.operands[0] を返す、srcvar は MEM_REF タイプ
	      srcvar = TREE_OPERAND (src, 0);
              //★★src_base は VAR_DECL タイプ
              //★★src_offset は 2（検証用プログラムで memmove の src に s + 2 を渡しているから）
	      src_base = get_addr_base_and_unit_offset (srcvar, &src_offset);
	      if (src_base == NULL)
		src_base = srcvar;

              //★★dest->expr.operands[0] を返す、destvar は MEM_REF タイプ
	      destvar = TREE_OPERAND (dest, 0);
              //★★dest_base は VAR_DECL タイプ
              //★★dest_offset は 0（検証用プログラムで dest に s を渡しているから）
	      dest_base = get_addr_base_and_unit_offset (destvar,
							 &dest_offset);
	      if (dest_base == NULL)
		dest_base = destvar;
	      if (!poly_int_tree_p (len, &maxsize))
		maxsize = -1;
	      if (SSA_VAR_P (src_base)
		  && SSA_VAR_P (dest_base))    //★★この条件が成立する
		{
                  //★★volatile があると operand_equal_p() が false になり
                  //★★memmove が memcpy に置き換えられてしまう
		  if (operand_equal_p (src_base, dest_base, 0)
		      && ranges_maybe_overlap_p (src_offset, maxsize,
						 dest_offset, maxsize))
		    return false;    //★★チェック 1箇所目
		}
	      else if (TREE_CODE (src_base) == MEM_REF
		       && TREE_CODE (dest_base) == MEM_REF)
		{
		  if (! operand_equal_p (TREE_OPERAND (src_base, 0),
					 TREE_OPERAND (dest_base, 0), 0))
		    return false;
		  poly_offset_int full_src_offset
		    = mem_ref_offset (src_base) + src_offset;
		  poly_offset_int full_dest_offset
		    = mem_ref_offset (dest_base) + dest_offset;
		  if (ranges_maybe_overlap_p (full_src_offset, maxsize,
					      full_dest_offset, maxsize))
		    return false;    //★★チェック 2箇所目
		}
	      else
		return false;    //★★チェック 3箇所目

	      fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
	      if (!fn)
		return false;
	      gimple_call_set_fndecl (stmt, fn);    //★★ここで memmove -> memcpy に置き換わる
	      gimple_call_set_arg (stmt, 0, dest);
	      gimple_call_set_arg (stmt, 1, src);
	      fold_stmt (gsi);
	      return true;
...


// gcc/gcc/tree-dfa.c

/* Returns the base object and a constant BITS_PER_UNIT offset in *POFFSET that
   denotes the starting address of the memory access EXP.
   Returns NULL_TREE if the offset is not constant or any component
   is not BITS_PER_UNIT-aligned.  */

tree
get_addr_base_and_unit_offset (tree exp, poly_int64_pod *poffset)
{
  return get_addr_base_and_unit_offset_1 (exp, poffset, NULL);
}


/* Returns the base object and a constant BITS_PER_UNIT offset in *POFFSET that
   denotes the starting address of the memory access EXP.
   Returns NULL_TREE if the offset is not constant or any component
   is not BITS_PER_UNIT-aligned.
   VALUEIZE if non-NULL is used to valueize SSA names.  It should return
   its argument or a constant if the argument is known to be constant.  */

tree
get_addr_base_and_unit_offset_1 (tree exp, poly_int64_pod *poffset,
				 tree (*valueize) (tree))
{
  poly_int64 byte_offset = 0;

  /* Compute cumulative byte-offset for nested component-refs and array-refs,
     and find the ultimate containing object.  */
  while (1)
    {
      switch (TREE_CODE (exp))
	{

...

	case MEM_REF:
	  {
	    tree base = TREE_OPERAND (exp, 0);
	    if (valueize
		&& TREE_CODE (base) == SSA_NAME)
	      base = (*valueize) (base);

	    /* Hand back the decl for MEM[&decl, off].  */
	    if (TREE_CODE (base) == ADDR_EXPR)
	      {
		if (!integer_zerop (TREE_OPERAND (exp, 1)))
		  {
		    poly_offset_int off = mem_ref_offset (exp);
		    byte_offset += off.force_shwi ();
		  }
		exp = TREE_OPERAND (base, 0);
	      }
	    goto done;
	  }


// gcc/gcc/tree.h

#define SSA_VAR_P(DECL)							\
	(TREE_CODE (DECL) == VAR_DECL					\
	 || TREE_CODE (DECL) == PARM_DECL				\
	 || TREE_CODE (DECL) == RESULT_DECL				\
	 || TREE_CODE (DECL) == SSA_NAME)

領域が重複している場合は、1箇所目のチェックに引っかかります。不思議なことに、配列 s の宣言から volatile を外して動かすと、1箇所目のチェックに引っかかりますが、volatile を付けるとチェックに引っかからなくなります。

int main(int argc, char *argv[])
{
	volatile char s[] = PRE STR;    //★★volatile を外すと __builtin_memcpy() への置き換えが発生しなくなる
	char *p = (char *)s;
	size_t sz_pre = strlen(PRE);
	size_t sz = strlen(p) - sz_pre + 1;

本来は volatile があろうがなかろうが 1箇所目のチェックに引っかからないとおかしいですが、volatile があるときは、なぜか 1箇所目のチェックを通過してしまいます。

長くなってきたので、続きはまた次回。

GCC を調べる - memmove の folding その 3

目次: GCC を調べる - まとめリンク

前回は memmove() を memcpy() に置き換える条件をチェックしているコードを紹介しました。より詳細に見ていきたいと思います。ここまで細かい話になると、もはや自分以外の誰得なのか全くわかりませんけど、そんなことを気にしてはいけません。

volatile の有無で何が変わるか？

前回紹介したチェック箇所のうち volatile の有無で動きが変わるのは、下記の operand_equal_p() です。

// gcc/gcc/gimple-fold.c

	      if (SSA_VAR_P (src_base)
		  && SSA_VAR_P (dest_base))    //★★この条件が成立する
		{
                  //★★volatile があると operand_equal_p() が false を返し、
                  //★★memmove が memcpy に置き換えられてしまう
		  if (operand_equal_p (src_base, dest_base, 0)
		      && ranges_maybe_overlap_p (src_offset, maxsize,
						 dest_offset, maxsize))
		    return false;    //★★チェック 1箇所目
		}


// gcc/gcc/fold-const.c

/* Return nonzero if two operands (typically of the same tree node)
   are necessarily equal. FLAGS modifies behavior as follows:

   If OEP_ONLY_CONST is set, only return nonzero for constants.
   This function tests whether the operands are indistinguishable;
   it does not test whether they are equal using C's == operation.
   The distinction is important for IEEE floating point, because
   (1) -0.0 and 0.0 are distinguishable, but -0.0==0.0, and
   (2) two NaNs may be indistinguishable, but NaN!=NaN.

   If OEP_ONLY_CONST is unset, a VAR_DECL is considered equal to itself
   even though it may hold multiple values during a function.
   This is because a GCC tree node guarantees that nothing else is
   executed between the evaluation of its "operands" (which may often
   be evaluated in arbitrary order).  Hence if the operands themselves
   don't side-effect, the VAR_DECLs, PARM_DECLs etc... must hold the
   same value in each operand/subexpression.  Hence leaving OEP_ONLY_CONST
   unset means assuming isochronic (or instantaneous) tree equivalence.
   Unless comparing arbitrary expression trees, such as from different
   statements, this flag can usually be left unset.

   If OEP_PURE_SAME is set, then pure functions with identical arguments
   are considered the same.  It is used when the caller has other ways
   to ensure that global memory is unchanged in between.

   If OEP_ADDRESS_OF is set, we are actually comparing addresses of objects,
   not values of expressions.

   If OEP_LEXICOGRAPHIC is set, then also handle expressions with side-effects
   such as MODIFY_EXPR, RETURN_EXPR, as well as STATEMENT_LISTs.

   If OEP_BITWISE is set, then require the values to be bitwise identical
   rather than simply numerically equal.  Do not take advantage of things
   like math-related flags or undefined behavior; only return true for
   values that are provably bitwise identical in all circumstances.

   Unless OEP_MATCH_SIDE_EFFECTS is set, the function returns false on
   any operand with side effect.  This is unnecesarily conservative in the
   case we know that arg0 and arg1 are in disjoint code paths (such as in
   ?: operator).  In addition OEP_MATCH_SIDE_EFFECTS is used when comparing
   addresses with TREE_CONSTANT flag set so we know that &var == &var
   even if var is volatile.  */

bool
operand_compare::operand_equal_p (const_tree arg0, const_tree arg1,
				  unsigned int flags)
{
  bool r;
  if (verify_hash_value (arg0, arg1, flags, &r))
    return r;

...

  /* If ARG0 and ARG1 are the same SAVE_EXPR, they are necessarily equal.
     We don't care about side effects in that case because the SAVE_EXPR
     takes care of that for us. In all other cases, two expressions are
     equal if they have no side effects.  If we have two identical
     expressions with side effects that should be treated the same due
     to the only side effects being identical SAVE_EXPR's, that will
     be detected in the recursive calls below.
     If we are taking an invariant address of two identical objects
     they are necessarily equal as well.  */
  if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST)
      && (TREE_CODE (arg0) == SAVE_EXPR
	  || (flags & OEP_MATCH_SIDE_EFFECTS)
	  || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1))))
    return true;  //★★volatile がないときは、このチェックに引っかかるが、volatile があると引っかからない

...

変化する箇所を見つけましたので、条件を全部バラして volatile の有無でどの条件が変化するか調べます。GCC はこういう訳のわからない if 文を連発してくるため、非常に解析が大変です……。

// ★★下記のように条件を全て展開して差分を調べる

int a, b, c, d, e, f, g;

a = arg0 == arg1;
b = ! (flags & OEP_ONLY_CONST);
c = TREE_CODE (arg0) == SAVE_EXPR;
d = flags & OEP_MATCH_SIDE_EFFECTS;
e = ! TREE_SIDE_EFFECTS (arg0);    //★★この条件が変わる
f = ! TREE_SIDE_EFFECTS (arg1);    //★★この条件が変わる
g = ppa && ppb && (ppc || ppd || (ppe && ppf));

/*
 * volatile なし
 *   (a, b, c, d, e, f, g)
 *   (1, 1, 0, 0, 1, 1, 1)
 * volatile あり
 *   (a, b, c, d, e, f, g)
 *   (1, 1, 0, 0, 0, 0, 0)
 *
 * volatile ありのときは side_effects_flag が 1 になる。
 */


// gcc/gcc/tree.h

/* In any expression, decl, or constant, nonzero means it has side effects or
   reevaluation of the whole expression could produce a different value.
   This is set if any subexpression is a function call, a side effect or a
   reference to a volatile variable.  In a ..._DECL, this is set only if the
   declaration said `volatile'.  This will never be set for a constant.  */
#define TREE_SIDE_EFFECTS(NODE) \
  (NON_TYPE_CHECK (NODE)->base.side_effects_flag)


//★★参考: side_effects_flag を設定する場所
// gcc/gcc/c-family/c-common.c

/* Apply the TYPE_QUALS to the new DECL.  */

void
c_apply_type_quals_to_decl (int type_quals, tree decl)
{
  tree type = TREE_TYPE (decl);

  if (type == error_mark_node)
    return;

  if ((type_quals & TYPE_QUAL_CONST)
      || (type && TREE_CODE (type) == REFERENCE_TYPE))
    /* We used to check TYPE_NEEDS_CONSTRUCTING here, but now a constexpr
       constructor can produce constant init, so rely on cp_finish_decl to
       clear TREE_READONLY if the variable has non-constant init.  */
    TREE_READONLY (decl) = 1;
  if (type_quals & TYPE_QUAL_VOLATILE)
    {
      TREE_SIDE_EFFECTS (decl) = 1;    //★★ここで設定する
      TREE_THIS_VOLATILE (decl) = 1;
    }
  if (type_quals & TYPE_QUAL_RESTRICT)
    {
      while (type && TREE_CODE (type) == ARRAY_TYPE)
	/* Allow 'restrict' on arrays of pointers.
	   FIXME currently we just ignore it.  */
	type = TREE_TYPE (type);
      if (!type
	  || !POINTER_TYPE_P (type)
	  || !C_TYPE_OBJECT_OR_INCOMPLETE_P (TREE_TYPE (type)))
	error ("invalid use of %<restrict%>");
    }
}

もし src や dest に volatile 修飾子が付いていると、side_effects_flag がセットされます。このフラグがセットされていると、GCC はアドレスをチェックすることなく、問答無用で src と dest は「等しくない」と判断します。その結果 src と dest は重なっていないことになって、memmove() を memcpy() に置き換える最適化が働きます。

正直な感想としては GCC バグってるだろ……と思いますが、volatile 変数はいつ書き換わってもおかしくないので、memmove() を memcpy() に置き換えて、動作がおかしくなっても規格違反にはならない？うーん、良くわかりませんね。

ちなみに Clang/LLVM はこのような最適化は行いません。memmove() は memmove() の呼び出しのままです。

x86_64 環境の事情

さらに厄介なことに x86_64 の glibc は memmove() を呼ぶべき場面で memcpy() を呼んでも、正常に動いてしまいます。検証用のプログラムを下記のように変えます。

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

#define PRE "AB"
#define STR "0123456789abcdefg"
#define NOP __asm__ volatile("nop;")

int main(int argc, char *argv[])
{
	volatile char s[] = PRE STR;
	char *p = (char *)s;
	size_t sz_pre = strlen(PRE);
	size_t sz = strlen(p) - sz_pre + 1;

	NOP;
	memcpy(p, p + sz_pre, sz);
	NOP; NOP;

	if (strcmp(p, STR) == 0) {
		printf("  OK: %s\n", p);
	} else {
		printf("  NG: %s\n", p);
	}
}

オプション -fno-builtin を指定すると、GCC が memcpy() をアセンブラへ展開しようとする最適化を抑制することができます。

$ gcc -O2 -Wall -g test.c -fno-builtin

$ objdump -drS a.out

...

        NOP;
    10b7:       90                      nop
        size_t sz = strlen(p) - sz_pre + 1;
    10b8:       48 83 c2 01             add    $0x1,%rdx
        memcpy(p, p + sz_pre, sz);
    10bc:       48 8d 74 1d 00          lea    0x0(%rbp,%rbx,1),%rsi
    10c1:       48 89 ef                mov    %rbp,%rdi
        size_t sz = strlen(p) - sz_pre + 1;
    10c4:       48 29 da                sub    %rbx,%rdx
        memcpy(p, p + sz_pre, sz);
    10c7:       e8 94 ff ff ff          callq  1060 <memcpy@plt>    ;★★memcpy を呼んでいる
        NOP; NOP;
    10cc:       90                      nop
    10cd:       90                      nop


$ ./a.out

  OK: 0123456789abcdefg

この動作でも C 言語仕様に違反するわけではありません。しかし GCC が間違って memmove() を memcpy() に置き換えるようなバグがあったときに、意図せず隠蔽してしまいます。ありがたいような、ありがたくないような実装ですね。

こっそり下がっている椅子

人によると思うんですけど、私は机に対して椅子の高さが低すぎると、肘で体重を支えるようになり異常に肩が痛くなります。肩が痛いのは嫌なので椅子の高さを調節していたはずなのに、なぜか最近また肩が痛くなってきました。

これはおかしいと思って椅子の高さを確認すると、いつの間にか下がっています。高さ調整機能がヘタっているのか？時間とともにジワジワ下がっているようです。

なんてことするんだ、やめてー。

メモ: 技術系？の話は Facebook から転記しておくことにした。

OpenCL を調べる - まとめリンク

目次: OpenCL を調べる - まとめリンク

一覧が欲しくなってきたので作りました。一部 OpenVX の話も含まれています。

• 初めての OpenVX
• 初めての OpenVX on ARM
• OpenVX on OpenCL
• OpenCL と ICD
• OpenCL の OSS 実装 pocl を調べる その 1 - 動かしてみよう
• OpenCL の OSS 実装 pocl を調べる その 2 - 独自アクセラレータのテンプレート実装を眺める
• OpenCL の OSS 実装 pocl を調べる その 3 - デバイス数の取得処理
• OpenCL の OSS 実装 pocl を調べる その 4 - デバイスのパラメータを渡す環境変数
• OpenCL の OSS 実装 pocl を調べる その 5 - デバイスの初期化
• OpenCL の OSS 実装 pocl を調べる その 6 - OpenCL カーネルのビルド
• OpenCL の OSS 実装 pocl を調べる その 7 - pocl と LLVM と OpenCL カーネルビルド
• OpenCL の OSS 実装 pocl を調べる その 8 - pocl と Clang/LLVM の引数

3階に住んで 20年

実家を出て 20年が経ちました。振り返ると、9割「3階に住んで」います。自分の意志で借りた部屋に限れば、全て 3階です。住所の遍歴はこんな感じ。

• 大学の寮: 113号室（4階建て）1年
• つくば: 308号室（3階建て）6年
• 会社の寮: 2階？（10階建て） 1年
• 大阪: 301号室（4階建て）10年
• 東京: 306号室（5階建て）2年

こう書くと、3階に恨みでもあるか、憑りついている地縛霊みたいですが、私は人間です。さておき真面目な話、1階の部屋と 3階の部屋（2〜5階もほぼ同条件）を比べ下記の点が気に入っています。

• 明るい
• 外から部屋が見えない
• 最悪、階段で生活できる（災害時など）

こちらから不動産屋に「3階がいい」と 1度も言ったことはないので、1度くらい 4階や 5階と巡り合っても不思議はなかったはずですが、結局ずっと 3階でした。謎の縁ですね。

メモ: 技術系の話は Facebook から転記しておくことにした。

たかいところこわい

3階で思い出したんですが、私は高所恐怖症らしく、背丈の 2〜3倍くらいの高さから下を見ると、動悸がして手から変な汗が出ます。

崖、高い吊り橋など、誰でも怖いところは当然怖いんですけど、他の人が怖くないのに、私だけ怖がっている（＝理解してもらえない）恐怖スポットとして、

• 歩道橋
• 地面が見える階段（踏み板が網やガラスなどのタイプ）
• 向こうが見える階段（蹴り込み板がないタイプ、例えばこれの「デザイン階段」みたいなやつ）
• 2階以上で、足下までガラスの窓
• 2階以上で、向こうが見える柵（※）

（※）自分の背の半分以下の柵、高さがあっても頭が通るくらいの隙間が空いてる柵は怖いです。

階段の板の名前

私が怖いと感じるタイプの階段（パナソニックのサイトから引用）

何が怖いの？と聞かれますが、説明が難しいです。強いて言えば「一歩踏み出したら隙間に吸い込まれそうな恐怖感」でしょうか。隙間から落ちることはないと理解していても、それでも怖いから不思議です。

観光地の「景観スポット」はたいてい恐怖スポットです。さらに良くないことに、周りの人は私が冗談を言ってるように聞こえるようで、ふざけて段差側に押されたりします。本当に恐怖です。勘弁して……。

いろいろある恐怖症

Facebook ではいくつかコメントいただいて、興味深かったです。高いところが怖いというのは割と普遍的ですが、怖さの感じるポイントや、感じ方は人それぞれです。

閉所恐怖症なんてのも教えてもらいました。そういうのもあるのか。この年になるとどこかに閉じ込められるという経験をすることはほぼないので、自分が閉所恐怖症なのかどうかすらわからないですね。

メモ: 技術系の話は Facebook から転記しておくことにした。階段の板の名前の図を追加。

GCC を調べる - デバッグ環境再び

目次: GCC を調べる - まとめリンク

去年あたりに GCC のデバッグ環境について書きました（2019年 5月 17日の日記参照）。GDB で GCC の動作を調べる際に、最適化が効いていると色々デバッグ時に不都合が生じます。例えば、

• ブレークポイントが設定できない箇所が生じる（インライン関数、最適化で消える部分など）
• 関数コールのバックトレースが不完全、動作と合わない（インライン関数、末尾最適化で ret が消える場合など）
• 引数、ローカル変数の値が optimized out されて読めない

通常のアプリケーションだと気になりませんが、相手は魔界 GCC です。勝手にブレークポイントがずれてもらってはたまったものではないです。こういうときは GCC のビルドオプションを変えて、最適化を全て OFF にしてしまうと見やすいです。

環境は Debian Testing です。GCC は 8.3 を使っています。

$ mkdir build
$ cd build

$ ../configure \
  --prefix=`pwd`/_install \
  --enable-languages=c,c++ \
  --disable-libsanitizer \
  --disable-bootstrap \
  CFLAGS="-O0 -g -fno-inline" \
  CXXFLAGS="-O0 -g -fno-inline"

$ make -j8
$ make install

私は C と C++ だけ使えれば良いので、--enable-languages=c,c++ を指定して、ついでにビルド時間短縮しています。C 以外の言語（Fortran など）に用事がある場合は、適宜足してください。Debian Testing で GCC 8.3 をビルドするとなんでか libsanitizer がビルドエラーになった（深追いしてません）ので、--disable-libsanitizer を付けて回避しました。環境によっては要らないかも？

また、ブートストラップモードだと、ビルドに時間がかかりすぎるので --disable-bootstrap で無効にしています。ビルドオプションは "-O0 -g -fno-inline" 最適化なし、デバッグ情報あり、インライン展開なし、です。

インストール先はどこでも良いですが、インストールするディレクトリは、build 下の _install ディレクトリにしています。build ディレクトリと一緒に消せて、間違って古いバイナリを使う心配がほぼないため、最近お気に入りのインストール先です。

最適化ありの場合

オプション -O2 -g でビルドしたバイナリを使って、GDB でインライン関数にブレークポイントを設定すると、こんなふうになります。

/* Set the implicit flag for a builtin function.  */

static inline void
set_builtin_decl_implicit_p (enum built_in_function fncode, bool implicit_p)
{
  size_t uns_fncode = (size_t)fncode;

  gcc_checking_assert (BUILTIN_VALID_P (fncode)
		       && builtin_info[uns_fncode].decl != NULL_TREE);

  builtin_info[uns_fncode].implicit_p = implicit_p;    //★ここにブレークポイントを設定★
}

$ gdb /path/to/gcc/build/_install/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/cc1

(gdb) b tree.h:5245
Breakpoint 1 at 0x7cc7c3: tree.h:5245. (2 locations)

(gdb) r -quiet -imultiarch x86_64-linux-gnu a.c -dumpbase a.c -mtune=generic \
  -march=x86-64 -auxbase a -g -O2 -Wall -std=c99 -o zzzzzzzz.s

Breakpoint 1, set_builtin_decl_implicit_p (implicit_p=true, fncode=12304)
    at ../../gcc/tree.h:5245
5245      builtin_info[uns_fncode].implicit_p = implicit_p;

(gdb) p uns_fncode

$1 = <optimized out>

一応ブレークはしますが、表示がおかしいです。引数の順序が逆ですし、fncode の値もおかしい（16 のはず）です。ローカル変数は最適化によって消されて print 不可能です。

#0  set_builtin_decl_implicit_p (implicit_p=true, fncode=12304)
    at ../../gcc/tree.h:5245
#1  gimplify_addr_expr (expr_p=expr_p@entry=0x7ffff76682e0, pre_p=pre_p@entry=0x7fffffffd600, post_p=post_p@entry=0x7fffffffd190)
    at ../../gcc/gimplify.c:6051
#2  0x000000000084301d in gimplify_expr (expr_p=0x7ffff76682e0, pre_p=<optimized out>, post_p=<optimized out>, gimple_test_f=<optimized out>, fallback=<optimized out>)
    at ../../gcc/gimplify.c:11581
#3  0x0000000000846a55 in gimplify_call_expr (expr_p=0x7ffff77eaee0, pre_p=0x7fffffffd600, want_value=<optimized out>)
    at ../../gcc/gimplify.c:3308
#4  0x00000000008436d6 in gimplify_expr (expr_p=0x7ffff77eaee0, pre_p=<optimized out>, post_p=<optimized out>, gimple_test_f=<optimized out>, fallback=<optimized out>)
    at ../../gcc/gimplify.c:11506
#5  0x0000000000843c0e in gimplify_stmt (seq_p=<optimized out>, stmt_p=<optimized out>)
    at ../../gcc/gimplify.c:6690
#6  gimplify_statement_list (pre_p=<optimized out>, expr_p=0x7ffff743ddd0)
    at ../../gcc/gimplify.c:1764
#7  gimplify_expr (expr_p=0x7ffff743ddd0, pre_p=<optimized out>, post_p=<optimized out>, gimple_test_f=<optimized out>, fallback=<optimized out>)
    at ../../gcc/gimplify.c:11963
#8  0x0000000000848f42 in gimplify_stmt (seq_p=0x7fffffffd600, stmt_p=0x7ffff743ddd0)
    at ../../gcc/gimplify.c:6690
#9  gimplify_bind_expr (expr_p=expr_p@entry=0x7ffff744b1c0, pre_p=pre_p@entry=0x7fffffffd7e8)
    at ../../gcc/gimplify.c:1331
#10 0x000000000084344b in gimplify_expr (expr_p=0x7ffff744b1c0, pre_p=<optimized out>, post_p=<optimized out>, gimple_test_f=<optimized out>, fallback=<optimized out>)
    at ../../gcc/gimplify.c:11735
#11 0x0000000000847508 in gimplify_stmt (seq_p=0x7fffffffd7e8, stmt_p=0x7ffff744b1c0)
    at ../../gcc/gimplify.c:6690
#12 gimplify_body (fndecl=0x7ffff744b100, do_parms=<optimized out>)
    at ../../gcc/gimplify.c:12735
#13 0x00000000008478e6 in gimplify_function_tree (fndecl=fndecl@entry=0x7ffff744b100)
    at ../../gcc/gimplify.c:12900
#14 0x00000000006f6ab0 in cgraph_node::analyze (this=0x7ffff74472e0)
    at ../../gcc/cgraphunit.c:670
#15 0x00000000006f8e68 in analyze_functions (first_time=<optimized out>)
    at ../../gcc/cgraphunit.c:1131
#16 0x00000000006f99c3 in symbol_table::finalize_compilation_unit (this=0x7ffff7658100)
    at ../../gcc/cgraphunit.c:2691
#17 0x0000000000a689fb in compile_file ()
    at ../../gcc/toplev.c:480
#18 0x00000000005bbe3d in do_compile ()
    at ../../gcc/toplev.c:2132
#19 toplev::main (this=this@entry=0x7fffffffda9e, argc=<optimized out>, argc@entry=17, argv=<optimized out>, argv@entry=0x7fffffffdba8)
    at ../../gcc/toplev.c:2267
#20 0x00000000005be0cf in main (argc=17, argv=0x7fffffffdba8)
    at ../../gcc/main.c:39

このケースだとバックトレースに抜けはなさそうですが、表示される引数に optimized out が多く、何が渡されたのかわかりません。

最適化なしの場合

ビルドオプション -O0 -g -fno-inline でビルドして、GDB でインライン関数にブレークを設定します。

$ gdb /path/to/gcc/build/_install/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/cc1

(gdb) b tree.h:5245
Breakpoint 1 at 0x7cc7c3: tree.h:5245. (2 locations)

(gdb) r -quiet -imultiarch x86_64-linux-gnu a.c -dumpbase a.c -mtune=generic \
  -march=x86-64 -auxbase a -g -O2 -Wall -std=c99 -o zzzzzzzz.s

Breakpoint 1, set_builtin_decl_implicit_p (fncode=BUILT_IN_ATAN2F,
    implicit_p=true) at ../../gcc/tree.h:5245
5245      builtin_info[uns_fncode].implicit_p = implicit_p;

(gdb) p uns_fncode

$1 = 16

引数の enum も名前で出ていますし、ローカル変数も表示できます。

#0  set_builtin_decl_implicit_p (fncode=BUILT_IN_ATAN2F, implicit_p=true)
    at ../../gcc/tree.h:5245
#1  0x0000000000b55843 in gimplify_addr_expr (expr_p=0x7ffff76682e0, pre_p=0x7fffffffd3f0, post_p=0x7fffffffcc08)
    at ../../gcc/gimplify.c:6051
#2  0x0000000000b636a5 in gimplify_expr (expr_p=0x7ffff76682e0, pre_p=0x7fffffffd3f0, post_p=0x7fffffffcc08, gimple_test_f=0xb16def <is_gimple_call_addr(tree_node*)>, fallback=1)
    at ../../gcc/gimplify.c:11581
#3  0x0000000000b4f52c in gimplify_call_expr (expr_p=0x7ffff77eaee0, pre_p=0x7fffffffd3f0, want_value=false)
    at ../../gcc/gimplify.c:3308
#4  0x0000000000b6336e in gimplify_expr (expr_p=0x7ffff77eaee0, pre_p=0x7fffffffd3f0, post_p=0x7fffffffcf58, gimple_test_f=0xb5411f <is_gimple_stmt(tree)>, fallback=0)
    at ../../gcc/gimplify.c:11506
#5  0x0000000000b571dd in gimplify_stmt (stmt_p=0x7ffff77eaee0, seq_p=0x7fffffffd3f0)
    at ../../gcc/gimplify.c:6690
#6  0x0000000000b4bcb9 in gimplify_statement_list (expr_p=0x7ffff743ddd0, pre_p=0x7fffffffd3f0)
    at ../../gcc/gimplify.c:1764
#7  0x0000000000b647a5 in gimplify_expr (expr_p=0x7ffff743ddd0, pre_p=0x7fffffffd3f0, post_p=0x7fffffffd208, gimple_test_f=0xb5411f <is_gimple_stmt(tree)>, fallback=0)
    at ../../gcc/gimplify.c:11963
#8  0x0000000000b571dd in gimplify_stmt (stmt_p=0x7ffff743ddd0, seq_p=0x7fffffffd3f0)
    at ../../gcc/gimplify.c:6690
#9  0x0000000000b4ad3a in gimplify_bind_expr (expr_p=0x7ffff744b1c0, pre_p=0x7fffffffd708)
    at ../../gcc/gimplify.c:1331
#10 0x0000000000b63d56 in gimplify_expr (expr_p=0x7ffff744b1c0, pre_p=0x7fffffffd708, post_p=0x7fffffffd558, gimple_test_f=0xb5411f <is_gimple_stmt(tree)>, fallback=0)
    at ../../gcc/gimplify.c:11735
#11 0x0000000000b571dd in gimplify_stmt (stmt_p=0x7ffff744b1c0, seq_p=0x7fffffffd708)
    at ../../gcc/gimplify.c:6690
#12 0x0000000000b6610a in gimplify_body (fndecl=0x7ffff744b100, do_parms=true)
    at ../../gcc/gimplify.c:12735
#13 0x0000000000b66740 in gimplify_function_tree (fndecl=0x7ffff744b100)
    at ../../gcc/gimplify.c:12900
#14 0x00000000009798ad in cgraph_node::analyze (this=0x7ffff74472e0)
    at ../../gcc/cgraphunit.c:670
#15 0x000000000097aa60 in analyze_functions (first_time=true)
    at ../../gcc/cgraphunit.c:1131
#16 0x000000000097e71a in symbol_table::finalize_compilation_unit (this=0x7ffff7658100)
    at ../../gcc/cgraphunit.c:2691
#17 0x0000000000e79db0 in compile_file ()
    at ../../gcc/toplev.c:480
#18 0x0000000000e7c68a in do_compile ()
    at ../../gcc/toplev.c:2132
#19 0x0000000000e7c966 in toplev::main (this=0x7fffffffda7e, argc=18, argv=0x7fffffffdb88)
    at ../../gcc/toplev.c:2267
#20 0x00000000019e07e6 in main (argc=18, argv=0x7fffffffdb88)
    at ../../gcc/main.c:39

バックトレースの引数表示もうまくいっているようです。

GCC を調べる - デバッグ環境再び（ブートストラップモード）

目次: GCC を調べる - まとめリンク

前回（2021年 3月 29日の日記参照）は configure オプションに --disable-bootstrap を指定してブートストラップモードを無効にしてビルドしました。ブートストラップモードが有効なときについても、メモしておこうと思います。

ブートストラップモードはホストのコンパイラで STAGE1 コンパイラをビルドし、STAGE1 コンパイラを使って STAGE2 と STAGE3 コンパイラをビルドして、ビルド結果に食い違いがないことを比較するモードです。ライブラリのビルドなどに使われる（最終的にインストールされる）のは STAGE3 のコンパイラのようです。3回 GCC をビルドするので、ビルド時間は非ブートストラップモードの 3倍近い時間がかかります。

ビルドオプションの変え方

ブートストラップモードのときは configure に CFLAGS, CXXFLAGS を指定する方法は使えません。代わりに GCC のマニュアルに記載がある通り make BOOT_CFLAGS="-O0 -g -fno-inline" bootstrap とすれば良いです。

こちらがおそらく正規の手順で、configure に CFLAGS, CXXFLAGS を指定する方法は邪道なんでしょうけど、ブートストラップモードはビルドが遅くて辛いんだよなー……。

$ mkdir build
$ cd build

$ ../configure \
  --prefix=`pwd`/_install \
  --enable-languages=c,c++

$ make -j8 BOOT_CFLAGS="-O0 -g -fno-inline" bootstrap
$ make install

ただし BOOT_CFLAGS の指定は STAGE1 には効きません。STAGE1 だけは常に手堅い安定したオプションでビルドされます。

# gcc/Makefile.in

...

# Flags to pass to stage2 and later makes.  They are defined
# here so that they can be overridden by Makefile fragments.
BOOT_CFLAGS= -g -O2
BOOT_LDFLAGS=
BOOT_ADAFLAGS= -gnatpg

...

# Defaults for all stages; some are overridden below.

STAGE_CFLAGS = $(BOOT_CFLAGS)    ★★STAGE_CFLAGS = BOOT_CFLAGS★★
STAGE_TFLAGS = $(TFLAGS)
STAGE_CONFIGURE_FLAGS=@stage2_werror_flag@

# Defaults for stage 1; some are overridden below.
STAGE1_CFLAGS = $(STAGE_CFLAGS)    ★★STAGE1_CFLAGS = STAGE_CFLAGS★★
STAGE1_CXXFLAGS = $(CXXFLAGS)
@if target-libstdc++-v3-bootstrap
# Override the above if we're bootstrapping C++.
STAGE1_CXXFLAGS = $(STAGE1_CFLAGS)
@endif target-libstdc++-v3-bootstrap

...

# By default, C and C++ are the only stage1 languages, because they are the
# only ones we require to build with the bootstrap compiler, and also the
# only ones useful for building stage2.

STAGE1_CFLAGS = @stage1_cflags@    ★★STAGE1_CFLAGS だけ無理やり上書きされる★★
STAGE1_CHECKING = @stage1_checking@
STAGE1_LANGUAGES = @stage1_languages@

当然ですが STAGE2 と STAGE3 には設定が反映されます。STAGE1 コンパイラを手動で使って何かビルドする人はほぼいないと思うので、特に問題ないでしょう。