コグノスケ

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

目次: Linux

その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のアナライザで見ればわかりますよ？でもアナライザなんか普通の人は持ってませんよ。パッケージから出した途端に見分けが付かなくなるなんて、一般消費者からしてみたら辛すぎません？