コグノスケ

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

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

JIS 配列キーボードと OADG 配列キーボード

今まで、いわゆる日本語配列のキー配列のことを漠然と JIS 配列と呼んでいましたが、どうもこれは正確ではないようです。

技術者たるもの、規格を粗末に扱ってはいけませんよね？？

JIS 配列を定めているのは JIS X 6002-1980「情報処理系けん盤配列」です。この配列を見ると一目瞭然ですが、アルファベット、スペースなどは一致するものの、他のキーは全く違う位置にあったり、そもそもなかったりします。規格書は有料（1,100円）ですが、PFU のサイトで JIS 配列の図をタダで拝めます。

JIS X 6002 のキーボード配列（PFU のサイトより）

PFU のサイトへのリンク:
https://www.pfu.fujitsu.com/hhkeyboard/pfutechreview/section3.html

現状、主流の日本語キー配列は OADG（The PC Open Architecture Developers Group）が規格化した配列です。OADG は 2004年に解散していますが、規格書は Internet Archive で見ることができます。

Internet Archive: OADG テクニカル・リファレンス ハードウェア編 1991年へのリンク:
https://archive.org/details/OADG1991/

規格の付録 A を見ると、

• OADG 104 型（英語配列）
• OADG 109 型（日本語配列）
• OADG 109A 型（109 型と同じだが、- や ^ キーの刻印が違う）

OADG 104 型（英語配列）

OADG 109 型（日本語配列）

OADG 109A 型

OADG 109 型（109A 型と異なる部分を示した）

の 3つが書かれています。市販のキーボードは、各社ともに適当に魔改造しているため、OADG 規格と全く同じキー配列のキーボードは存在しないと思います。たぶん。

実例を出すと、Logicool K295 はかなり 109A に近いです。しかし、右 Windows キーが欠けています（このタイプ、俗に 108 キーなどと呼ばれていますね）。

Logicool K295 のキー配列

FILCO Majestouch も素直な 109A に近いですが、右 App キーがなく、右 Windows キーが Fn キーに置換されています。

FILCO Majestouch Convertible 2 のキー配列

私の場合は、最下段は 左 Ctrl, 左 Win, 左 Alt, スペース, 右 Alt, 右 Ctrl しか使わないので、K295 や Majestouch のように使わないキーが欠けていても気になりませんが、使う人からすると、何てことするの！？という気分になるでしょう。

さらに言うと、無変換、変換、ひらがなキーも使わないので、使っているキーの種類だけ考えたら、いわゆる英語配列（OADG 104 型）で十分に思えます。しかし日本語配列で練習したため、英語配列は記号類を間違えまくります。私物で購入したことはありません。打てて損はないので、もうちょい修行しても良いかもしれませんね……？

メモ: 技術系の話は Facebook から転記しておくことにした。写真追加、加筆。

新キーボード購入

先日の在宅勤務環境改善（2021年 2月 12日の日記参照）にて、デュアルディスプレイにしたところ、ノート PC 本体が邪魔になってしまったので、机の上からどけました。

当然、ThinkPad 本体のキーボードには手が届きませんから、ワイヤレスキーボード Logicool K295 を買いました。Amazon で 1,900円くらいでした。K295 は変なキーも少ないし、静かで良いですが、キーの認識が渋いです。私の場合、打鍵力が足りず人差し指担当のキー（T, U など）の誤打が多発してイライラします。

買ってすぐ買い替えるのもどうかと悩みましたけど、あまりに誤打が多く慣れるまで辛そうだったので、さっさと諦め FILCO の Majestouch 赤軸を買いました。ヨドバシで 15,000円くらいでした。Majestouch はキーが戻るとき＆底打ちしたとき「カーン！」と響く鐘のような音がやかましい以外は、非常に良いキーボードです。

キーボード使用歴

今まで、キーボードは 標準的なキーボード（※）であれば、高くても安くても使い心地が気になることはないと思っていました。しかし今回 K295 がどうも合わなかったことから、実は自分とキーボードの相性って結構あるのか？と疑問に感じるようになりました。

（※）OADG 109A 型の配列で、カーソルキー、ファンクションキー等の位置を移動していないキーボードのこと。

まずはキーボードの使用履歴を書き出してみます。

相性とか全く気にならなかった。

• DELL の標準キーボード
• Gateway の標準キーボード
• HP の標準キーボード
• IBM/Lenovo ThinkPad X, E シリーズ
• Logicool K270
• Majestouch 赤軸
• NEC VersaPro
• Owltech の安いキーボード
• RealForce 108UBK
• サンワサプライの安いキーボード
• SONY VAIO Type-G
• TOSHIBA Dynabook R73

誤打しやすかった。

• Let's Noteシリーズ（理由: キーの形が横長）
• Logicool K295（理由: キーの認識が渋い）
• Logicool K340（理由: カーソル、ファンクションキー配置が変）

まともに打てなかった。

• HappyHacking（理由: キー配置が変すぎる）

以前 K340 や HHK で懲りて、特殊なキー配列のキーボードに触らなくなったので、コンパクト系のキーボードの利用歴はほぼゼロです。そもそもまともに打てないし、レビューできません。

ほとんど PC 付属キーボード、ノート PC のキーボードばかりです。これはもしや、勝手に安物だと思いこんでいた PC 付属の標準キーボード、実は質が高かったのではなかろうか？

大事な製品に標準で付属するものですし、高級ではないにせよ、あまりに変なものはつけませんよね。これが答えなのでは、という気がしてきました。

Slideshare 初利用

Slideshare を初めて使いました。LinkedIn のアカウントが必要なのは知りませんでした。偶然 LinkedIn のアカウントを持っていたので、すんなり登録できました。

USB PD はもっとわかりやすくしてほしい

試しに USB Type-C, USB PDケーブルとお友達になろうをアップロードしました。ダウンロードもできるし、スライド置き場として優秀ですね。みんな使うわけだ……。

スライドの話もしておくと、USB Type-C ケーブルがどうして何種類もあって、値段が全然違うのか、気になったので調べたことをまとめたものです。USB 初心者なので間違ってたらすみません。

最後まで分からなかったのは USB Power Delivery の 3A/5A ケーブルを見分ける方法です。何か無いんでしょうか。当然 USB PD のアナライザで見ればわかりますよ？でもアナライザなんか普通の人は持ってませんよ。パッケージから出した途端に見分けが付かなくなるなんて、一般消費者からしてみたら辛すぎません？