雨。 整形外科へは車で。
ついでに車でバイク屋さんに寄って、任意保険の更新手続きをする。 クレジットカードの期限はブランドによって自動更新の場合とそうでない場合があるらしく、イオンの VISA は更新されていた。 バイク屋さんの店長、iQ を見て珍しい車だと興味津々だったw 車好きでもこの車は知らない人多いよねw そうそう、また新しいバイクが出たみたいで。
V とついているけど並列 2 気筒エンジン。 アドベンチャーツアラーと言っていて見た目もなんかそれっぽいが、使い勝手的には GSR250S の後継といったところか。 エンジンは同系統だし車重も近いしメインスタンドまで付いている。
夜は、西田あい 7 周年記念コンサート @ 有楽町よみうりホール。2 階の関係者席あたり、ライトがまぶしい。 いろんなカバー曲もあって 2 時間ちょっとのコンサートだった。 アンコールで客席を回ってタッチ。 手は冷えていた。 で、しゃべりは、声だけ聞いていると柏木由紀なんかを思い出すトーンで、東京アクセントを意識してはいると思うのだが、結構な頻度で節々に鹿児島アクセントが現れる。 歌声は曲によってちょっと雰囲気が違うように思ったが、低めのトーンで歌っている時はどこか中島美嘉っぽかった。 歌手のコンサートだから、演奏の人達は脇役というか、あまり見えないんだけど、あの人達はすごいよなぁ。 ドラムとかベースとか、歌以上にミスれないし、プロの仕事って感じがする。 ベースの低音が良い感じに響いて楽しかった。 あ、西田あいも楽しそうに歌っていたので、これからも楽しく歌っていってほしい。 鹿児島アクセントが適度に混ざっているのも、同郷の人間は喜ぶのでぜひそのままで... (^^;
謎の call だと思われていたところのデータ構造を突き止めた。
(gdb) p *(struct obstack *)0x0000000001b0f4d0
$1 = {chunk_size = 4064, chunk = 0x2493dc0, object_base = 0x1b0f508 "",
next_free = 0x1b0f508 "", chunk_limit = 0x0, temp = {tempint = 0,
tempptr = 0x0}, alignment_mask = 48, chunkfun = 0x0, freefun = 0x0,
extra_arg = 0x0, use_extra_arg = 0, maybe_empty_object = 0, alloc_failed = 0}
この chunkfun というのを呼び出そうとして落ちている。 これは初期化の際にセットされているはずであり、おかしい。 他にも freefun もおかしいし、alignment_mask は文字通りビットマスクのはずでたぶん 7 が入っていないといけないはずなのに、48 が入っているのもおかしい。chunk_limit もよく見てないけどたぶんポインターが入っていなきゃいけないのに NULL である。 逆に chunk_size の 4064 は正常値だ。
そんなわけで例の 64 バイトズレ問題で初期化ルーチンが正常に動かなかった可能性を検討したけど、いくらなんでもこんな動きにはならないと思うんだよなぁ。 どこかでぶっ壊した可能性のほうが高そうな感じが。 これはわからん。
よく寝た日。
東京都議会議員選挙投票日。
そうそう、きのうは有楽町に行くのに神田で乗り換えようとしていたけど、たくさんの人が降りるのを見て気が変わり、東京駅丸の内口から有楽町駅前まで歩いた。 はとバス乗り場? の先に「JR 東京駅」ってあるから何かと思えば京葉線の出入り口だった。 帰りは東京駅に向かわず、品川に行って、駅の中の TOKYO 豚骨 BASE という店で夕食をとり (さすがにきれいにしている店でスープもそんなに臭く無かった)、そこから山手線で新宿に出て、中央線快速に乗り換えようと思っていたのに目の前の各駅停車につられて乗り換えてしまい、その後、次の乗換駅で待ち時間が長くなる可能性に気づいて、中野で快速に乗り換えるという謎パターンの帰宅であった。
AMD は交換対応をしているそうだが、交換品でも問題解決していないという話があるらしく盛り上がりそうな気配。 うちのは交換をお願いしていない。 発生頻度が低く動画エンコード程度だと影響はなさそうだし、何より謎解きパズルは楽しいので。
現状わかっているのは、%rip の 64 バイト手前の命令が唐突に実行され始めるケースがあることと、その状態で call 命令があれば %rip の位置 (call 命令の 64 バイト後ろ) をベースにスタックに戻り番地が積まれ、相対番地指定であれば呼び出し先も 64 バイトずれる (%rip そのものがズレる、%rip と実行される命令の対応としては元に戻る)、そんな感じ。 自分の考えでは、あらゆるトラブルをこの現象だけで説明できるのではないかと思って、調べているのだがなかなか難しいパターンが多い。 何度もやっていると、もう分析済みのものが何度も出てきて、うっとうしいのでこれもちょっと cc1 をハックしてみた:
3054169,3054173c3054171,3054174 < 113f539: 48 83 ea 01 sub $0x1,%rdx < 113f53d: 49 89 55 00 mov %rdx,0x0(%r13) < 113f541: e9 b8 fc ff ff jmpq 113f1fe < 113f546: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1) < 113f54d: 00 00 00 --- > 113f539: 48 81 ea 01 00 00 00 sub $0x1,%rdx > 113f540: 49 89 55 00 mov %rdx,0x0(%r13) > 113f544: e9 b5 fc ff ff jmpq 113f1fe > 113f549: 0f 1f 80 00 00 00 00 nopl 0x0(%rax)
これは、%rip=0x113f57d の時に 113f53d の命令が実行されたように見える問題の話で、ちょうどいい具合に 64 バイト手前に命令があるからそんなことになるのでは、という思いから、わざと違う機械語に変えて命令の位置をずらしてみたものである。 即値のビット数を変えただけで、命令そのものの並びは変わっていないので、マイクロコードになったらもはや同じなのではないかな。 そうでもないのかな。 これで出なくなるんならおもしろいというか、もちろんマイクロコードキャッシュの観点で言えばそんな変なアドレスはキャッシュにのらないわけだから、マイクロコードキャッシュの問題なのであればこれで出なくなって正しいような気もする。
全体的には cc1 の bitmap という処理に絡む部分でトラブルが起きている頻度が非常に高そうな感じはする。 今は VMM 無しで見ているので、分岐情報は取れていないし、割り込みのタイミングも不明。 そのため、%rip がズレたところから、割り込みをきっかけにして元に戻った、というパターンがあるとしても、そこは推測でしかない。
bash segfault on Ryzen - GitHub
他人様の segfault 分析の様子である。bash らしい。%rip は 0x00000000004370d0、ページフォールトのアクセス先が 0x6dfb44 だという。 命令の通りのスタックポインターは全然違うところを指しており、何か違う命令を実行しているかのようだ。 じゃあ 64 バイト手前か? と言えば、64 バイト手前のちょうどいい位置に命令はなく、何か違うようだ。
じゃ、どの命令かと言えば、レジスターの一覧を見ても、それらしきアドレスはない。 ふむ。 他に疑わしいのは %rip 相対指定か。%rip を引けば 0x6dfb44 - 0x00000000004370d0 = 0x2a8a74 で、何かそれっぽいアドレスはないだろうか? と探すと、0x0000000000465ef0 のあたり。 ちょうど、直前の call 命令が呼び出しているサブルーチンの中だ。 ただし、0x0000000000465ef0 の命令であれば 8 バイト命令で 0x2a8a78(%rip) なので、0x00000000004370d0 + 8 + 0x2a8a78 = 0x6dfb50 で計算が合わない。 見ていくと 0x0000000000465f10 の命令なら 6 バイト命令で 0x2a8a6e(%rip) なので、0x00000000004370d0 + 6 + 0x2a8a6e = 0x6dfb44 でぴったりである。
スタックの内容も含めて見れば、0x00000000004370cb の call 命令を実行、0x465ef0 番地から順に命令を実行していき、0x0000000000465f0b の call 命令も実行し、普通に ret したところで、%rip は正しく 0x00000000004370d0 に移ったが、実際に実行しようとした命令は 0x0000000000465f10 だった、ということになる。64 バイトズレだけじゃないんだな、という、新たな発見であった。
なお、手元に残っている core は、ここに載せていないものも含め何種類も 64 バイトズレで説明できそうなものがある。 きのうの深夜に起きていた segfault は mv コマンドの中だったが、それも 64 バイトズレとそのまま jmp を実行して機械語命令の途中に飛んでしまったということで説明できそう。 あと、きのうの夜中に回した内容では、きのうわざと命令位置をずらした件については一度もその周辺での問題は残っていなかった。 やはり、命令境界がちょうど 64 バイト手前に来るかどうかというのがポイントになるようだ。 ただし上述の他人様の Ryzen での分析もあるので、話はやっかいだ。 後は発生箇所が何パターンか偏っているのが説明できればいいんだけどなぁ。
天気予報に出てきた数字は最高気温 35 度。 気象庁アメダスによれば府中市幸町の今日の最高気温は 33.5 度 (15:04)。 そうでもない? いやいや、19 時に 30.9 度、21 時に 30.0 度というのがこの暑さを語る数字である。 さすがに 30 度台ってのは、直射日光無くてもバイクで暑さを感じるような気温である。
朝は山手線でブレーキ故障のためダイヤ乱れという情報を Twitter で眺めて、新宿駅ホームの大混雑で巻き添えを食って中央線も遅れているとのことだったので、迷わずバスで行ったら明らかに定刻の列車が駅に進入するのが見えて、とっくにダイヤは回復していたということだ。
夜は台風襲来。 帰宅時間帯にはまだ強風域にすら入っていなかったけど、雨はそれなりに降り出していた。
じゃがいも消費作戦につき、豚軟骨とタマネギとじゃがいもとおでんの素をスロークッカーに放り込んで煮込んだ。 料理が美味いというよりは、素材が美味い... 歯ごたえすらもなくなったとろっとろの軟骨に新タマネギに新じゃがいも、まー美味いよね。 豚軟骨はその安さもうれしい。 近所のスーパーで 100g 100 円ちょっとくらいだった。 問題はいつも売っているわけじゃないところか。
Skype は今月から旧バージョンのクライアントが使えないことになっているはずなのだが、サインインしっぱなしの手元の Skype は引き続きそれらしき表示をしている。 オンライン中の人数は 59M 人あたりと出ているし、ユーザーのステータスも更新されているように見える。 どうなっているのだろう。 この PC は CPU が Atom Z530 なので 64bit に移行できず、32bit 版の Skype for Linux の提供が終わった今となってはもう Skype を動かしておくことはできないのだが (qemu-user を使う手はあるのか?)、サインアウトするまでは使えるのだろうか?
暑い。
夜はまたざーっと雨が降った。 九州北部はなんだかやばいことになっているらしい。 数年前の鬼怒川みたいにならなければいいが...
温度はちゃんと測っていないが、Seek Thermal で見てみたところ、RAM の下のほうにあるマザーボードのヒートシンクが、負荷を掛けると熱々 (65 度くらい) になる様子が観察できた。 あと CPU の後ろ側、背面パネルとの間の空間もやはり熱々になっていた。CPU の上側は 43 度あたりでそうでもなく、電源装置の冷却ファンによる排熱効果だろうか。 排気ケースファンをつけていないので、CPU の排熱がたまってしまうのかも知れない。
まーでも CPU より怪しいのはマザーボードについているヒートシンクのほうかな。 あれは何用なのかな、電源まわり? 電源が不安定になればそれは当然 CPU にとっても致命的なので、そのへんもちゃんと冷却したほうがいいんだろうな。 とはいえ、segfault トラブルに関して言えば、温度が悪いというよりは、何らかの設計上のしきい値みたいなものが甘かったというようなところが少しありそうな気はする。
なにやら SOC 電圧とやらを上げたらどうかという話を見かけたので、意味もわからず試しに +0.2V 上げてみたのだが、普通に segfault は起きた。 今まで起きたことのないアドレスではあったが、すぐにいつも通りの 64 バイトズレ問題のひとつであることがわかった。 ページフォールト時点での %rip の指す命令がページフォールトを起こす命令でなく、64 バイト手前に原因となる命令があるという極めてわかりやすいパターン。
Skype が使えなくなるといわれつつまだ使えているっぽいけど、そういう 64bit アプリしか提供されなくなったものが QEMU User Emulator で動かせるかと思ったら、どうもこれは致命的な問題を抱えているようだ。 試しに busybox を動かしてみたらこの通りである:
$ file busybox busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically l inked, for GNU/Linux 2.6.32, BuildID[sha1]=45ccabb327ad2416d72b467d491dbc83d5eb e97d, stripped $ uname -m i686 $ qemu-x86_64 ./busybox ls -l / total 1 drwxr-xr-x 25 root root 696 Mar 2 2007 drwxr-xr-x 25 root root 696 Mar 2 2007
ls すらまともに動かないとは、絶望感漂う挙動である。 これは Debian GNU/Linux jessie (oldstable) の QEMU だが、jessie-backports から引っ張ってきてもだめみたいなのでバージョンのせいではなさそうだ。64 ビット環境上では大丈夫なので、システムコールの変換にまつわる問題かとも思ったが (getdents(2) で使われる unsigned long 型の大きさが 32 ビットと 64 ビットで違うため変換が必要)、それなら反対に 64 ビット環境で 32 ビットバイナリーを qemu-i386 で動かすのもうまくいかないはずだ。 しかしなぜかそれはうまくいくのであった。
$ file busybox busybox: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=bd18da7da6195be9b099237b15d183b07b7 f908b, stripped $ uname -m x86_64 $ qemu-i386 ./busybox ls -l /etc/systemd total 8 -rw-r--r-- 1 root root 823 May 10 2014 logind.conf drwxr-xr-x 5 root root 4096 Apr 19 2014 system
2017 年 7 月九州北部豪雨はだいぶ被害が出ているらしい... 2 年弱前の平成 27 年 9 月関東・東北豪雨の被害を見てしまった記憶がよみがえる。 っていうか、平成 26 年 8 月豪雨というのもあったし、去年は熊本地震があったし、日本全国災害続きだな...
昨日の夜ちょっと変な風に寝てしまってまたちょっと痛みがアレ。 ひどくはないけど痛みが出ている感じがする。
DAZN で Formula One フリー走行を珍しく見てみた。 なんか動きがなめらかになっている気がするぞ!? と思って調べたら 50fps になったとのうわさ。 前回のレースでは気づかなかったが、まだだったのかどうか。 サッカーは先月の途中からそうなっていたみたいだ。 ディスプレイのリフレッシュレートとの差は気になるところではあるが、設定を確認したら 85Hz にしてあったw 75Hz のほうが良いかも知れないが、59.94fps も見るしなぁ。 ま、何でもいいけど 25fps とは比べものにならない。 これで不満は無くなった感じ。
問題が出たら早急にそれを検出して止める的なことができないか、gcc をコンパイルする時に何か仕掛けを突っ込む手はないかを考えている。 とりあえず、gcc に -include オプションを付ければ強引に好きなヘッダーファイルを読ませることができる。 それで、asm 文を入れればアセンブリ言語の出力に好きな内容を追加でき、それでアセンブラーのマクロでも入れれば適当な命令を差し替えることができるかも知れない。
しかし %rip の値をチェックするには lea 命令を使いたい。 そうするとレジスターを破壊しなければならない。 どうにかしてレジスターを予約できないか? というと、できるらしい。
register int x asm("%r10");
こんな感じで書けば、%r10 を予約できる。 ただし、%r10 は通常関数で破壊して良いレジスターなので、以下のような警告が出る。
z.c:1:14: warning: call-clobbered register used for global register variable
これはライブラリ関数などを呼んだときに変数の中身が壊されうるのだからコンパイラーとしては当然の警告か。 今回は無理やりアセンブリ言語で lea 命令を挿入したいとすれば、破壊しても良いほうが都合がいい。Red zone が使われている場合はスタックを好きに使えないので、こうしてレジスターを予約できているほうがやりやすい。
後は比較のためにフラグレジスターを破壊してしまうので、まぁ例えば cmp 命令の直前に入れる分には困らないが、mov 命令の間に挟み込むのは手間だ。 あと条件ジャンプをどうするか、異常検出時にジャンプで int3 を埋め尽くした領域にジャンプするとかかな? でも %rip ズレたところからジャンプしたら元をたどりにくくなる? cmov は即値指定できないんだっけか、うーん。 比較したあと予約しておいたレジスターに目印の値を入れてから条件ジャンプでいいかな?
ま、そんな凝ったことしても再現しなくなるかも知れないし、いつものように変なところで飛んで変なところアクセスして落ちるパターンは引き続き避けられないし、難しいところだ。
藤野。5 回乗ってベストタイムは 39.771 秒くらい。
クッソ暑い一日。 午前中に耳鼻科に寄って、藤野には午後一に車で行って 1 時間半ほどでさっさと帰ってシャワー浴びて昼寝した。 暑かった。
気象庁アメダスの府中市幸町の記録した最高気温が 34.0 度 (13:01) だもんね、相模湖はそこまででは無かったかも知れないけどそれにしても良く 40 秒切れたな。 路面温度が高いせいでタイヤはあっという間に熱々でグリップしすぎるし、エンジンはお疲れモードだし、良いタイムが出せるコンディションでは全く無かった...
車もエアコンつけっぱにしていたらシガーソケット電圧がずっと 13.7V 前後。 いつもなら 14.1V 前後なのだが、たぶん温度か何かの条件で低めの電圧に制御されていたものと思われる。 というのは、試しに一時的にエアコン・送風を止めてアクセルペダルを離したら、いつものように 14.6V 前後まで上がったので、発電系統の故障によるものではない。 ということで、エンジンルーム内は相当な温度になっていたものと思われ、こうなるとエンジンオイルを 0W-20 の代わりに 5W-30 にしたのは精神的な安心感が多少ある。
cc1 を gcc のソースからビルドする。Ubuntu の gcc パッケージのビルドを始めたら、build/gcc/ ディレクトリに cc1 ができていて、これかな。 ビルド自体は並列ビルドが行われないためか 11 時間も掛かった。 しかも成功したように見えたが dmesg 見るとたくさんの trap や segfault が残されていて本当に大丈夫なのか? 適当にファイルを消して make cc1 したら再コンパイルが行われるようだから、これがあればいいようだ。
さて、Makefile をちょっといじる。make cc1 の時に出てきたコンパイラーオプションの中に -fprofile-use という目立つものがあったので、それを検索すると 3 箇所。 その後ろに -include /root/hoge.h を付ける。 んで、そのヘッダーファイルの中身はこれだ:
register int DUMMY_dummy asm("%r10");
asm(".include \"/root/hogeasm.s\"");
こないだ見つけた方法で %r10 レジスターをコンパイラーに使わせないようにした上で、アセンブリ言語のほうにも .include でファイルを読み込ませる。 そっちのファイルの内容はこれ:
.macro defhoge i
.macro \i o:vararg
hoge \i,\o
.endm
.endm
.macro hoge i,o:vararg
.purgem \i
lea (%rip),%r10
cmp $.,%r10
jne hoge_fail
\i \o
defhoge \i
.endm
defhoge cmpb
defhoge cmpw
defhoge cmpl
defhoge cmpq
.text
.rept 512
int3
.endr
hoge_fail:
.rept 512
int3
.endr
マクロを使ってやってみたのだが、もうちょっと、マシな方法があるかも知れない。vararg を使わないと (%rax,%rbx,8) 形式の指定を変な風に解釈されてしまったので vararg を使うのと、呼び出しがネストしてしまわないように .purgem でマクロを消して使ってから再定義するという怪しい方法を使っている。 で、cmpb/cmpw/cmpl/cmpq の 4 命令の直前に、%rip が正しいかどうかの比較テストをする短いテストコードを挿入している。 不一致の時は hoge_fail に飛ぶ。 これは 1,024 個の int3 の真ん中で、多少ズレても int3 があるという構成。
これで cc1 はずいぶん大きくなってしまったが (笑)、ビルドテストを試みたところ int3 が実行されるケースを見ることができた。 ひとつ目は以下の場所で停止:
(gdb) x/i $pc => 0x1640b41 <hoge_fail+65>: int3
%r10 の付近を観察 (長いシンボル名はカット):
(gdb) p/x $r10 $1 = 0x1161aba 1161a61: 4c 8b 9c fc b0 00 00 mov 0xb0(%rsp,%rdi,8),%r11 1161a68: 00 1161a69: 4d 0f a3 e3 bt %r12,%r11 1161a6d: 0f 83 7d 01 00 00 jae 1161bf0 1161a73: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 1161a7a: 49 81 fa 7a 1a 16 01 cmp $0x1161a7a,%r10 1161a81: 0f 85 79 f0 4d 00 jne 1640b00 <hoge_fail> 1161a87: 45 39 e0 cmp %r12d,%r8d 1161a8a: 0f 86 60 03 00 00 jbe 1161df0 1161a90: 8b 43 04 mov 0x4(%rbx),%eax 1161a93: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 1161a9a: 49 81 fa 9a 1a 16 01 cmp $0x1161a9a,%r10 1161aa1: 0f 85 59 f0 4d 00 jne 1640b00 <hoge_fail> 1161aa7: 41 39 c4 cmp %eax,%r12d 1161aaa: 0f 85 3a 02 00 00 jne 1161cea 1161ab0: 8b 7b 08 mov 0x8(%rbx),%edi 1161ab3: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 1161aba: 49 81 fa ba 1a 16 01 cmp $0x1161aba,%r10 1161ac1: 0f 85 39 f0 4d 00 jne 1640b00 <hoge_fail>
見事に %r10 の位置にも 64 バイト手前にも上で足したテストコードが入っている。%r10 が指す位置の命令が本当に実行されていたなら、クラッシュはしない。 実際にはそのへんで 64 バイト手前にワープしてしまったと考えられる。 なお、いくつかのレジスターの内容を確認したが、直前までは普通に実行されていたと思われる。
(gdb) x/x 8+$rbx 0x3f30a68: 0xffffffff (gdb) p/x $rdi $2 = 0xffffffff (gdb) p/x $eax==$r12d $4 = 0x1 (gdb) x/x 4+$rbx 0x3f30a64: 0x00000018 (gdb) p/x $eax $5 = 0x18
ふたつ目は以下の場所で停止:
(gdb) x/i $pc => 0x16b58e1 <hoge_fail+65>: int3
%r10 の付近を観察:
(gdb) p/x $r10 $1 = 0x13b0188 13b0123: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 13b012a: 49 81 fa 2a 01 3b 01 cmp $0x13b012a,%r10 13b0131: 0f 85 69 57 30 00 jne 16b58a0 <hoge_fail> 13b0137: 66 83 f8 2b cmp $0x2b,%ax 13b013b: 0f 84 0f 1a 00 00 je 13b1b50 13b0141: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 13b0148: 49 81 fa 48 01 3b 01 cmp $0x13b0148,%r10 13b014f: 0f 85 4b 57 30 00 jne 16b58a0 <hoge_fail> 13b0155: 66 83 f8 35 cmp $0x35,%ax 13b0159: 0f 85 21 08 00 00 jne 13b0980 13b015f: 48 8b 6b 08 mov 0x8(%rbx),%rbp 13b0163: 48 8b 53 10 mov 0x10(%rbx),%rdx 13b0167: 0f b7 4d 00 movzwl 0x0(%rbp),%ecx 13b016b: 48 89 54 24 30 mov %rdx,0x30(%rsp) 13b0170: 4c 8d 15 00 00 00 00 lea 0x0(%rip),%r10 13b0177: 49 81 fa 77 01 3b 01 cmp $0x13b0177,%r10 13b017e: 0f 85 1c 57 30 00 jne 16b58a0 <hoge_fail> 13b0184: 66 83 f9 35 cmp $0x35,%cx 13b0188: 0f 84 02 0e 00 00 je 13b0f90
今度は %r10 の 64 バイト手前にテストコードが入っている。%r10 が指す位置の直前にも比較があるため、そこが実行されていたとしてもその時点では問題は発生していなかったと考えられる。 見た感じ 13b0177 から 64 バイト手前を実行し始めたと見るのが正解かなと。
(gdb) x/gx 0x30+$rsp 0x7ffd4322adb0: 0x00007f220d3cd830 (gdb) p/x $rdx $4 = 0x7f220d3cd830 (gdb) x/x 8+$rbx 0x7f220cdf2c38: 0x00007f220d20d300 (gdb) p/x $rbp $5 = 0x7f220d20d300 (gdb) p/x $ax $6 = 0x35
こんな感じで、現状うちの環境では 64 バイトズレ問題ばかりが発生している。 これまでの core で原因を特定できていないものもあったけど、それはどこかで 64 バイトズレたまま普通に実行が済んでしまった場合、後からその場所を特定するのは困難だからだと思っている。 今回のこのテストコード入り cc1 を使えば、頻繁に %rip チェックが走るので、そう簡単には 64 バイトズレたままの実行は継続されないと思う。
スーパーフォーミュラ第 3 戦、富士スピードウェイ。 この暑さでは現地に行く元気も起きないので、BS フジの生中継で観戦。 スタート直後の周回では一部ガチャガチャやり合っていたが、その後は静かに進む、かと思いきや、パンクやらブレーキやらエンストやら何やらとトラブルが多発。 暑さの影響もあるだろうか。 終盤の 4 位関口を先頭にしたバトルがおもしろくて、これが DRS のないバトルだよなぁと。 もし DRS があったらたぶん 1, 2 周で抜けてしまってその後は引き離されて終わりだっただろう。 タイヤの関係でかなりのペース差があったはずなのに、ストレートスピードを重視したセッティングと思われる関口がストレートで微妙に引き離し、オーバーテイクを難しくした。Formula One の DRS はオーバーテイクを増やしたが、レースの見所は減ってしまったんだよな。
東京競馬場の花火大会。 最後に音楽に合わせてドカドカっと、かなりの数が短時間に一気に打ち上げられて、煙で花火が隠れるほどになり、そこらじゅうに火薬のにおいと煙が充満して終了となったのには笑った。 帰るタイミングをミスって人と自転車の大渋滞だった。 花火大会に来ると、モータースポーツで音とにおいが云々と言う人がいるのを思い出すな。 花火大会の音とにおいが無くなったらと思うとちょっと寂しいもんね。 でもなー、モータースポーツの音はエネルギーの損失なので、最新技術を取り入れていくと静かになるのは避けられないもんかと。
DAZN の Formula One 本当に良くなってるな。50fps って聞くと変な数字だなと思うけど、十分だ。
ポケモン GO プラスの電池が減ってきたらしく、電池残量が少ないマークがポケモン GO の画面に出るようになったので、電池を買ってきた。 このところバイブレーターの振動が弱々しい感じになってきていたし、マークも出るようになったから替え時だな。 時々アプリ側の接続表示は切れているのに実際には切れていないパターンがあって、それで予期せぬ電池消費をしてしまったことがあるかも知れない。 スマートフォン側は ZenFone Max のバッテリーが大きすぎて、減りが早くても気づけないw
Powered by Tomsoft Diary System 1.7.4
Hideki EIRAKU