目次: RISC-V
昨日の続きです。64bit Linux環境のreboot() はmagicの符号拡張をしてもしなくても正常に動くという話をしました。
この話はrebootには限らないので、もっと一般化すると「64bit環境においてシステムコールの引数がレジスタ長(= 64bit)以下だった場合(例えばintが典型例)、どう扱うか?」となります。
動作を確認するにはデバッガで追えば早いでしょう。RISC-V 64bit向けに、
を用意して起動します。符号拡張を行わないmusl libc版のツールチェーンでbusyboxをビルドしてQEMU起動、GDBでアタッチします。
$ qemu-system-riscv64 \ -machine virt \ -net none \ -nographic \ -chardev stdio,id=con,mux=on \ -serial chardev:con -mon chardev=con,mode=readline \ -kernel linux/arch/riscv/boot/Image \ -initrd busybox/initramfs.cpio \ -s $ riscv64-unknown-linux-gnu-gdb linux/vmlinux (gdb) target remote :1234 ...
Linuxのシステムコールの実装は下記のようになります。SYSCALL_DEFINE() とはなんぞや?というところが気になると思いますが、今はひとまずシステムコール名の頭に __do_sys_ を付けた関数が定義されると理解しておけば大丈夫です。
//linux/kernel/reboot.c
SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd,
void __user *, arg)
{
...
ブレークポイントを __do_sys_rebootに仕掛けてQEMU側のコンソールでbusybox poweroffコマンドを実行します。
(gdb) b __do_sys_reboot Breakpoint 1 at 0xffffffff8002d860: file kernel/reboot.c, line 702. (gdb) c Continuing. Breakpoint 1, __do_sys_reboot (magic1=-18751827, magic2=672274793, cmd=1126301404, arg=0x4321fedc) at kernel/reboot.c:702 702 { (gdb) p/x $a0 $1 = 0xfffffffffee1dead
システムコールの引数は負の数(つまり0xffffffff_fee1dead)となっています。この関数に辿り着く前に符号拡張されるようです。
(gdb) bt #0 __do_sys_reboot (magic1=-18751827, magic2=672274793, cmd=1126301404, arg=0x4321fedc) at kernel/reboot.c:702 #1 0xffffffff8002dab2 in __se_sys_reboot (magic1=<optimized out>, magic2=<optimized out>, cmd=<optimized out>, arg=<optimized out>) at kernel/reboot.c:700 #2 0xffffffff80002fe2 in handle_exception () at arch/riscv/kernel/entry.S:231 Backtrace stopped: frame did not save the PC
バックトレースを見ると__se_sys_reboot() という関数も呼ばれています。この関数を調べるためにブレークを掛けて再度実行します。
(gdb) b __se_sys_reboot Breakpoint 1 at 0xffffffff8002daa0: file kernel/reboot.c, line 700. (gdb) c Continuing. Breakpoint 1, __se_sys_reboot (magic1=4276215469, magic2=672274793, cmd=1126301404, arg=1126301404) at kernel/reboot.c:700 700 SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, (gdb) p/x $a0 $1 = 0xfee1dead
システムコール例外ハンドラに渡ってきた引数magicはレジスタa0に入っていて、値は0xfee1deadです。__do_sys_reboot() や __se_sys_reboot() 関数を定義するSYSCALL_DEFINE() はマクロのため、デバッガから見てもソースコードが表示されません。
不思議なSYSCALL_DEFINE() マクロの仕組みは後日調べるとして、とりあえず今は逆アセンブルします。
(gdb) disas Dump of assembler code for function __se_sys_reboot: => 0xffffffff8002daa0 <+0>: addi sp,sp,-16 0xffffffff8002daa2 <+2>: sd s0,0(sp) 0xffffffff8002daa4 <+4>: sd ra,8(sp) 0xffffffff8002daa6 <+6>: addi s0,sp,16 0xffffffff8002daa8 <+8>: sext.w a2,a2 ★ 0xffffffff8002daaa <+10>: sext.w a1,a1 ★ 0xffffffff8002daac <+12>: sext.w a0,a0 ★ 0xffffffff8002daae <+14>: jal ra,0xffffffff8002d860 <__do_sys_reboot> 0xffffffff8002dab2 <+18>: ld ra,8(sp) 0xffffffff8002dab4 <+20>: ld s0,0(sp) 0xffffffff8002dab6 <+22>: addi sp,sp,16 0xffffffff8002dab8 <+24>: ret
RISC-Vのアセンブラを見たことない方のために補足すると、sext.wという命令はRISC-Vの符号拡張命令です。また引数はa0, a1, a2, a3, a4, a5レジスタを経由して渡されます。すなわち __se_sys_reboot() 関数はa0, a1, a2レジスタ(引数magic1, magic2, cmdに相当)を符号拡張して __do_sys_reboot() 関数に渡しています。
ここで当初の疑問が解消しますね。疑問の内容は下記の通りで、
答えは途中で符号拡張しているのでどちらでも問題なかった、というわけです。なるほどね。
ツールチェーンのビルドはcrosstool-NGなどでもできますし、面倒な場合はGitHubにUbuntu 20.04用の *.debファイルを置いたのでお使いください。
GNU libcの場合は、
またmusl libcの場合は、
をお使いください。
目次: RISC-V
タイトルに反して実はRISC-Vはあまり関係ないですが……。GNU libcとmusl libcの実装を見ていたら、64bit環境でrebootシステムコールの引数magicに、
がいることに気づきました。
Cライブラリのrebootの関数宣言はint reboot(int cmd) となっています。musl libcの場合0xfee1deadをキャストせずlong型の引数に渡します。符号拡張は行われず0x00000000_fee1deadがシステムコールの引数に渡されます。
// musl/src/linux/reboot.c
int reboot(int type)
{
return syscall(SYS_reboot, 0xfee1dead, 672274793, type);
}
// musl/arch/riscv64/syscall_arch.h
static inline long __syscall3(long n, long a, long b, long c)
{
register long a7 __asm__("a7") = n;
register long a0 __asm__("a0") = a;
register long a1 __asm__("a1") = b;
register long a2 __asm__("a2") = c;
__asm_syscall("r"(a7), "0"(a0), "r"(a1), "r"(a2))
}
一方のGNU libcの場合は、0xfee1deadをintにキャストしてからシステムコールに渡します。この値は負の数なので符号拡張が行われて0xffffffff_fee1deadがシステムコールの引数に渡されます。
// glibc/sysdeps/unix/sysv/linux/reboot.c
/* Call kernel with additional two arguments the syscall requires. */
int
reboot (int howto)
{
return INLINE_SYSCALL (reboot, 3, (int) 0xfee1dead, 672274793, howto);
}
// glibc/sysdeps/unix/sysv/linux/riscv/sysdep.h
# define internal_syscall3(number, arg0, arg1, arg2) \
({ \
long int _sys_result; \
long int _arg0 = (long int) (arg0); \
long int _arg1 = (long int) (arg1); \
long int _arg2 = (long int) (arg2); \
\
{ \
register long int __a7 asm ("a7") = number; \
register long int __a0 asm ("a0") = _arg0; \
register long int __a1 asm ("a1") = _arg1; \
register long int __a2 asm ("a2") = _arg2; \
__asm__ volatile ( \
"scall\n\t" \
: "+r" (__a0) \
: "r" (__a7), "r" (__a1), "r" (__a2) \
: __SYSCALL_CLOBBERS); \
_sys_result = __a0; \
} \
_sys_result; \
})
最初に気づいたときはどちらかがバグっている……?と勘違いしましたが、当たり前ですがどちらも正常に動きます。すなわちLinux側で何か対応しているはずです。続きはまた今度。
目次: Linux
昨日(2023年1月26日の日記参照)の続きです。タイトルに「日本語 → 英語」の順の文字列を表示させると英語がズレてしまう問題についてです。
ルック&フィールの設定からフォントを変えて試したところ、源ノ角ゴシックの一部の太さ(Normalのみ)でこの問題が発生することが分かりました。実際に見てもらった方が分かりやすいと思います。
原因が良くわからないままですが、とりあえず源ノ角ゴシックを使うならNormal以外の太さを選択することで英語が上にズレてしまう問題を回避できそうです。
NormalだろうがRegularだろうが同じフォントだと思っていたんですけど、何か違うんでしょうか??フォントのレンダリングは良くわからないね……。
目次: Linux
タイトルのままなのですが、普段使いしているLinux環境(Debian Testing, LXDE)にて英語の位置がたまにズレていることがあります。どういうときにズレるのか気になったので、いくつかパターンを試しました。残念ながら原因や直し方までは調べていないので良くわかりません。
結論を先に書いておくと、日本語のあとに英語を書くとズレます。英語のあとに日本語を書いてもズレません。不思議ですね。
この画像をキャプチャしているときに気が付いたのですが、Leafpadのテキストボックスでも同じ現象が発生していました。
何なんでしょうね?GTK+ の仕様なんでしょうか?
NetFlixのような老舗に属するVODサービスって一時期に一気に増えたよね?という印象を持っていたのですが、調べたことがなかったので調べがてらメモしておきます。
ベンダー | 創業国 | 創業国サービスイン | 日本サービスイン |
---|---|---|---|
Amazon | アメリカ | 2006 | 2015/09 |
Hulu | アメリカ | 2007 | 2011/09 |
NetFlix | アメリカ | 2007 | 2015/09 |
U-NEXT | 日本 | 2007 | 同左 |
注意点としては創業 = サブスクリプション開始、ではないことです。今やVODサービスといえば定額制度(サブスクリプション制度、サブスク)が当たり前ですが、以前は1つの動画に1度支払う制度(PPV: Pay-Per-View制度)が普通でした。
したがって老舗VOD企業達も創業時にサブスクリプション制度を展開していたとは限りません。例えばHuluはPPVで参入、サブスク(Hulu Plus)の開始は2010年です。
といった細かい話をあえて無視すれば「老舗VOD企業は2007年に出揃った」と言ってしまって良いでしょう。
リモートワークが当たり前になり家に居る時間が長くなりました。当然、家に居れば電気を使いますので電気代も上がります。2021年はそれで説明が付いたんですけど、去年2022年の電気代はライフスタイルの変化では説明できないほど明らかに高いです。何が起きたの……??
まずは今までの電気使用量をおさらいします。あ、ちなみに契約している電力会社はSymEnergy(公式サイトへのリンク)という会社です。
電気代を使用量で割ってkWh平均、いわゆる単価相当の数値を出します。厳密にいうと電気代は複数段階料金制のため、電気代を使用量で割っても単価は出せないのですが、飛びぬけて使用量が少なかったり多かったりした月はないので、細かいことは気にしなくて良いです。
予想はしていましたがkWh単価が1.5倍(2021/12: 28.00円/kWh, 2022/12: 40.96円/kWh)です。そりゃ高い訳だ……ヒエー勘弁してくれえ。
電気関係の話題でもう一つ。福島第一原子力発電所の事故は日本国民に原発アレルギーを引き起こしたようで、原子力発電所を動かすor動かさないであらゆる地域がもめています。ちなみに今の稼働率はどの程度でしょうか?
データは原子力規制委員会が公開していて(原子力発電所の現在の運転状況 - 原子力規制委員会)簡単に見ることができます。各発電所の出力も公開されていますが、ちょっとサボってWikipediaから数値を持ってきました。間違っていたらごめんなさい。
各電力会社ごとに運転状況をグラフにしました。灰色が廃炉(または廃炉検討中)、オレンジが停止中、青が運転中です。
見てのとおり関西、四国、九州以外は全く運転していません。定格出力をグラフにすると、保有量が多いのは東京(柏崎刈羽)、関西(美浜、大飯、高浜)ですが、ほとんど活かされていないことがわかります。
東京電力なんかは柏崎刈羽原発だけで821万kWも出力があって、東電管内の太陽光発電の「ピーク値」である1200万kWの7割を充足する発電量です。強いですね。
原子力発電所を新たに建てるか建てないは人によって思うところがあるでしょうけど、既に建ててあるのに使わず風化させるのは勿体ないなあと思います……。
目次: Windows
スマホ(Pixel 4a)をWindowsマシンに接続して、外した後にしばらくするとこんなエラーが出ます。不思議なことに、なぜか必ず3つ出ます。
エラー内容は「デバイスが応答しなくなっているか、デバイスとの接続が解除されています。」とのことですが、スマートフォンを外したのは2日以上前であり、外したときはエラーが出ていませんでした。
Spy++ で調べるとエラーのダイアログを出しているプロセスは0x16b8 = 5816です。
Process Explorerで調べるとエラーのダイアログを出しているのはsihost.exeで、親プロセスはUser Managerというサービスでした。なんでこのサービスがエラーを出し続けるんでしょうね……。Windowsはようわからんな。
ちなみにUser Managerを停止させることはできますが、Windowsの動きがおかしくなります。下手に弄らない方が良いです。
目次: Kindle
Kindle Fire HD 10の後釜として、Lenovo Tab M10 (3rd Gen, TB328FU) を買いました。ヨドバシで37,000円くらいでした。SoC UNISOC T610 (Cortex-A75 x 2, Cortex-A55 x 6)、RAM 4GB、Storage 64GBです。バッテリーは5000mAhらしい。UNISOCは中国系メーカー製のタブレットで採用されていますね。中国の国策の一環なんですかね?
RAMはそこそこあります。CPUやGPUはAnTuTuのスコアを見ると19万点くらいで、数年前のミドルエンド(Snapdragon 675)と同じくらいでした。10インチクラスのタブレットの中ではミドルエンド……いや、ローエンドくらいかなあ?私はタブレットでゲームをしたり、動画を見たりしないので何も問題ありません。
買う前から分かっていましたが、Kindleの本を買う手間は大幅に増えて面倒になりました。今まではKindle Fireから1クリックで買えましたが、これからは4手必要になって、めちゃくちゃ面倒です。
後から気づいたんですけど、本を買っても自動的にタブレットにダウンロードされない点も地味に不便です。イケてねーなあ。
目次: Kindle
Kindle Fireが壊れて起動しなくなったのは昨日お伝えしたとおりですが、本体が使えなくなる以上に困った事態が発生しました。なんと2022年分の既読/未読のデータ(約2,000冊分くらい)がきれいさっぱり消えました。
Kindle Fireの故障によって、近日のデータは消えても不思議はありません。が、1年分消えるとはどういう了見でしょうか?Kindleは既読/未読のデータを1年近くクラウド側に反映しなかった?実は1年前から故障していた?もうKindle Fireは起動しないので、原因を調べる術はありません。
Kindleの読書補助の機能は色々とおかしくて、ダウンロードフラグがバグったり、しおりが消えたり、購読位置が巻き戻ったり、色々と変な動きをします。そのなかで既読/未読フラグは堅牢で信用していましたが、こいつもダメみたいですね。
Kindleで信用できるデータは「購入済みフラグ」だけだと思います。このフラグが崩壊したら二重購入が発生しまくるのは目に見えているので、Amazonの利用自体をやめると思います。ECサイトの根幹機能ですし、さすがに大丈夫でしょう……きっと。
既読フラグを2,000冊分も吹っ飛ばしてくれたのは痛いですね。Kindle Fireの買いたい意欲がさらに下がりました、もう地の底に近いですよ……。
目次: Kindle
実家から東京に帰ってきてマンガを読もうと思ったら、なぜかKindle Fire HD 10の電源が切れていました。不審に思って電源ONするとホームアプリが無限に再起動してしまう病気になっていました。通常再起動でも、電源長押しの強制再起動でも、症状は改善せず。
Kindleアプリを起動すると「Kindleはお使いの端末でサポートされていません。お使いの端末が端末の製造元のAndroidの正式なバージョンを使用していること、また端末が最新バージョンに更新済みであることを確認してください。」という妙なエラーが出て全く動作しません。
再起動後1分くらいは操作できる猶予があることに気づいたので、起動直後に素早く工場初期化を選択しました。
が、残念ながらsystem recovery画面が表示されるようになってしまいました。さらに壊れたようです。ありゃー。
手始めにメニューの中で失敗してもダメージが少なそうな「wipe cache partition」を実行しました。意味はわからないですが、めちゃくちゃmountのエラーが出ます。eMMCが死んだのかなあ?
もはや直ることはほとんど期待していませんが、一応「wipe data/factory reset」も試しました。先ほどと同様にエラーが大量に出てます。ダメそうですね。
あと復帰できそうなメニューは「apply update from ADB」ですが、これを選んでもadb shellなどは弾かれるので何も調査できませんでした。adb sideloadしかできません。AmazonはKindleのOTAパッケージを公開していないので、使い物になりません。Amazonのサポート部門の人が使うための機能でしょうね。
もうできることはなさそうだな、と再起動したところfireの画面から先に進まなくなってしまい、見事に文鎮と化しました。あーあ……、ダメだなこりゃ……。
日記を見返すとKindle Fireを購入は2017年(2017年10月12日の日記参照)でした。5年間も頑張ってくれました。ありがとう。素直に諦めて次の機種に買い替えることにします。
今のところ考えている選択肢は2つです。
Kindle Fireは市場を破壊するレベルで安く、1クリックでマンガが購入できて非常に便利です。しかしトラブルの多さと、意味不明な変更を頻繁&勝手に入れるのがストレスフルです。初代+七代目の合計10年間使ったものの、嫌い度が増すばかりで、可能ならもう次機種の候補に入れたくありません……。
AndroidタブレットはKindle Fireと比べると高いです。あとかつてのAndroidのKindleアプリも1クリックでマンガが購入できましたが、Googleの嫌がらせにより2022年6月から購入できなくなりました(「Kindle」Androidアプリ、電子書籍の購入が不可にGoogle Playのポリシー変更で - ITmedia NEWS)。使い勝手は悪化しました。
Kindleアプリが不便になる前ならAndroidタブレット一択でしたけど、今はどちらもイマイチです。どうしたもんかねえ?
< | 2023 | > | ||||
<< | < | 02 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | 1 | 2 | 3 | 4 |
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | - | - | - | - |
合計:
本日:
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.2.20.
using GD bundled (2.1.0 compatible)(png support.)