コグノスケ

RISC-V 64bit Linuxとシステムコールと32bitの引数 その2 - Linuxの動作

目次: RISC-V

昨日の続きです。64bit Linux環境のreboot() はmagicの符号拡張をしてもしなくても正常に動くという話をしました。

この話はrebootには限らないので、もっと一般化すると「64bit環境においてシステムコールの引数がレジスタ長（= 64bit）以下だった場合（例えばintが典型例）、どう扱うか？」となります。

動作を確認するにはデバッガで追えば早いでしょう。RISC-V 64bit向けに、

• musl libcを使うツールチェーン（後述）
• GNU libcを使うツールチェーン（後述）
• linux
• busybox
• QEMU

を用意して起動します。符号拡張を行わない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() 関数に渡しています。

ここで当初の疑問が解消しますね。疑問の内容は下記の通りで、

• magic1に0xffffffff_fee1deadを渡す派（GNU libc）→ 符号拡張するが値は変わらず
• magic1に0x00000000_fee1deadを渡す派（musl libc）→ 符号拡張して0xffffffff_fee1deadにする

答えは途中で符号拡張しているのでどちらでも問題なかった、というわけです。なるほどね。

補足: ツールチェーンの準備

ツールチェーンのビルドはcrosstool-NGなどでもできますし、面倒な場合はGitHubにUbuntu 20.04用の *.debファイルを置いたのでお使いください。

GNU libcの場合は、

• riscv64-linux-glibc-binutils.deb
• riscv64-linux-glibc-headers.deb
• riscv64-linux-glibc.deb
• riscv64-linux-glibc-gcc.deb

またmusl libcの場合は、

• riscv64-linux-musl-binutils.deb
• riscv64-linux-musl-headers.deb
• riscv64-linux-musl.deb
• riscv64-linux-musl-gcc.deb

をお使いください。

RISC-V 64bit Linuxとシステムコールと32bitの引数 その1 - libcの実装

目次: RISC-V

タイトルに反して実はRISC-Vはあまり関係ないですが……。GNU libcとmusl libcの実装を見ていたら、64bit環境でrebootシステムコールの引数magicに、

• 0x00000000_fee1deadを渡す派（musl libc）
• 0xffffffff_fee1deadを渡す派（GNU libc）

がいることに気づきました。

musl libcとGNU libcの実装

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側で何か対応しているはずです。続きはまた今度。

LXDE + GTKで日本語と英語を混ぜるとズレる（続き）

目次: Linux

昨日（2023年1月26日の日記参照）の続きです。タイトルに「日本語 → 英語」の順の文字列を表示させると英語がズレてしまう問題についてです。

ルック＆フィールの設定からフォントを変えて試したところ、源ノ角ゴシックの一部の太さ（Normalのみ）でこの問題が発生することが分かりました。実際に見てもらった方が分かりやすいと思います。

源ノ角ゴシックJP Normal（英語が上にズレる）

源ノ角ゴシックJP Regular（英語がズレない）

原因が良くわからないままですが、とりあえず源ノ角ゴシックを使うならNormal以外の太さを選択することで英語が上にズレてしまう問題を回避できそうです。

NormalだろうがRegularだろうが同じフォントだと思っていたんですけど、何か違うんでしょうか？？フォントのレンダリングは良くわからないね……。

LXDE + GTKで日本語と英語を混ぜるとズレる

目次: Linux

タイトルのままなのですが、普段使いしているLinux環境（Debian Testing, LXDE）にて英語の位置がたまにズレていることがあります。どういうときにズレるのか気になったので、いくつかパターンを試しました。残念ながら原因や直し方までは調べていないので良くわかりません。

結論を先に書いておくと、日本語のあとに英語を書くとズレます。英語のあとに日本語を書いてもズレません。不思議ですね。

タイトルに日本語のみ表示

タイトルに英語、日本語の順で表示

タイトルに英語、日本語、英語の順で表示

タイトルに日本語、英語の順で表示（英語が上にズレる）

この画像をキャプチャしているときに気が付いたのですが、Leafpadのテキストボックスでも同じ現象が発生していました。

Leafpadのテキストボックスも同様の現象

何なんでしょうね？GTK+ の仕様なんでしょうか？

老舗VODサービスの開始時期

NetFlixのような老舗に属するVODサービスって一時期に一気に増えたよね？という印象を持っていたのですが、調べたことがなかったので調べがてらメモしておきます。

注意点としては創業 = サブスクリプション開始、ではないことです。今やVODサービスといえば定額制度（サブスクリプション制度、サブスク）が当たり前ですが、以前は1つの動画に1度支払う制度（PPV: Pay-Per-View制度）が普通でした。

したがって老舗VOD企業達も創業時にサブスクリプション制度を展開していたとは限りません。例えばHuluはPPVで参入、サブスク（Hulu Plus）の開始は2010年です。

といった細かい話をあえて無視すれば「老舗VOD企業は2007年に出揃った」と言ってしまって良いでしょう。

電気代が高いよ

リモートワークが当たり前になり家に居る時間が長くなりました。当然、家に居れば電気を使いますので電気代も上がります。2021年はそれで説明が付いたんですけど、去年2022年の電気代はライフスタイルの変化では説明できないほど明らかに高いです。何が起きたの……？？

まずは今までの電気使用量をおさらいします。あ、ちなみに契約している電力会社はSymEnergy（公式サイトへのリンク）という会社です。

過去4年間の電気使用量

電気代を使用量で割ってkWh平均、いわゆる単価相当の数値を出します。厳密にいうと電気代は複数段階料金制のため、電気代を使用量で割っても単価は出せないのですが、飛びぬけて使用量が少なかったり多かったりした月はないので、細かいことは気にしなくて良いです。

過去4年間のkWhあたりの電気代

予想はしていましたがkWh単価が1.5倍（2021/12: 28.00円/kWh, 2022/12: 40.96円/kWh）です。そりゃ高い訳だ……ヒエー勘弁してくれえ。

もったいない原子力発電所

電気関係の話題でもう一つ。福島第一原子力発電所の事故は日本国民に原発アレルギーを引き起こしたようで、原子力発電所を動かすor動かさないであらゆる地域がもめています。ちなみに今の稼働率はどの程度でしょうか？

データは原子力規制委員会が公開していて（原子力発電所の現在の運転状況 - 原子力規制委員会）簡単に見ることができます。各発電所の出力も公開されていますが、ちょっとサボってWikipediaから数値を持ってきました。間違っていたらごめんなさい。

各電力会社ごとに運転状況をグラフにしました。灰色が廃炉（または廃炉検討中）、オレンジが停止中、青が運転中です。

日本の原子力発電所の稼働割合

見てのとおり関西、四国、九州以外は全く運転していません。定格出力をグラフにすると、保有量が多いのは東京（柏崎刈羽）、関西（美浜、大飯、高浜）ですが、ほとんど活かされていないことがわかります。

日本の原子力発電所の稼働＆出力

東京電力なんかは柏崎刈羽原発だけで821万kWも出力があって、東電管内の太陽光発電の「ピーク値」である1200万kWの7割を充足する発電量です。強いですね。

原子力発電所を新たに建てるか建てないは人によって思うところがあるでしょうけど、既に建ててあるのに使わず風化させるのは勿体ないなあと思います……。