KMC 京都マイクロコンピュータ株式会社

続きを読む

C の規格に関するちょっとした話です。

今まで、extern が付いていない最上位宣言での変数宣言（グローバル変数）は、全て定義宣言になるのだと思っていたのですが、厳密には異なるそうです。

int x;         /* (1) */

int y = 0;     /* (2) */

extern int x;  /* (3) */

(1) と (2) は、単に初期値が与えられているかいないかだけの違いで、どちらも定義に見えます。

ところが、厳密には (2) だけが定義宣言で、(1) は仮定義という扱いになるのだそうです。続きを読む

このごろは組み込みソフトウェア開発でも C++ が使われるようになってきました。C から C++ に移行する際、おそらく誰もが一度は引っかかるのではないかという C++ の挙動について書きます。続きを読む

CNET Japan : Linuxの脆弱性を突くゼロデイエクスプロイトが公開に

Linux Kernel の脆弱性により、見慣れない GCC のコンパイルオプションが話題になっています。恥かしながら、私は今回の一件で始めて知りました。GCC の online manual を見る限り、少なくとも GCC 3.0.4 からは存在するオプションのようです。

GCC Manual 3.10 Options That Control Optimization -fdelete-null-pointer-checks

マニュアルの説明を読むと、既に一回ポインタを間接参照した後の NULL チェックは無意味だから削除するという、何の問題も無い最適化に見えます。

GCC 4.4.1 までは -O2,-O3,-Os で有効になっていたようですが、最新のマニュアルでは（一部のターゲットを除き）全ての最適化レベル（-O0 含む）で有効になると書いてあります。

このリンク元のブログ記事のコード

struct sock *sk = tun->sk;  // initialize sk with tun->sk

…

if (!tun)

    return POLLERR;  // if tun is NULL return error

を一見した時、何が問題なのかよくわからなかった (NULL チェックがあろうがなかろうが、NULL ポインタを参照した瞬間に SEGV が発生して kernel panic になるはず、と思った) のですが、kosaki さんの記事を読んで納得。

革命の日々 : 「Linux カーネルの zero-day exploit コード、リリースされる」への余談

Linux Kernel では、ユーザプロセスが 0 番地に mmap を実行することが可能なので、

(1) 0 番地を間接参照しても SEGV が発生しないようにできる。
(2) NULL チェックが GCC の最適化によって削除されてしまっている。
(3) Kernel が 0 番地にアクセスしてしまう。（任意のコードを実行させることができる。）

というメカニズムのようです。なるほど。

私は、これは GCC の問題というよりは、ポインタを NULL チェック無しでいきなり参照している Linux Kernel のコードの問題だと思います。しかし、Kernel などのセキュリティが重要なソフトウェアをビルドする際には、fno-delete-null-pointer-checks を付けておいた方が良さそうです。

# あるいは、NULL チェックが行われていないポインタ参照全てにデフォルトのチェックコードを挿入するようなオプションがあれば良いのかもしれません。

ベテラン技術者の S 先輩からコラムを 1 本いただきました。ありがとうございます。

---

ユーザインターフェースは、人それぞれの好みや世の中の流行などがあって万人受けする設計はとても難しい。色、一つをとっても、KMCのPARTNERでは、Windows Ver3.1の時代に設計されたので、当時Windows Ver 3.1の制約で中間色がほとんど使えなかったため、青色,黄色,黒色などはっきりした色をベースとしました。

現時点では、勿論PARTNERでも中間色設定ができるのですが、新たにその色のデフォルト変更しようとすると、社内でもユーザに確認しても賛成意見(最近のソフトにあわせるべき)と反対意見(PARTNERらしい色使いを残すべき)が拮抗して判断に迷うことも多くあります。

また、好みによってメニューを変えられる機能を付けても、多くのユーザは、標準設定で使うことが多そうです。

そこで、長い間デバッガの開発にたずさわってきた経験とそのデバッガを使ってきた経験からいえることは、デバッグ作業の特性上同じことの繰り返しが非常に多い事です。実は、CUI(コマンド入力)とコマンドヒストリ機能を使うのが早くて便利なのです。

• デバッグのファイルロード
• ブレークポイントの設定
• 変数参照
• ファイル参照

など、これらの同じ操作の繰り返しは、あまりGUIに向きません。GUIでは、メニューを選択してダイアログボックスが表示され、その項目に従って、データを設定すれば、視覚的でかつ初心者でも分かり易いのは勿論、他のソフトウェアを使った経験もそのまま有効です。

しかし、何度もマウス操作とクリックおよびキー入力、また、表示の変化がディスプレイ上のいろんな場所に変わっていく(メニュー、ダイアログ、タグなど)ので認識に時間がかかります。

一方、CUI(コマンド入力)では、コマンドを覚えないと使えないし、パラメータの意味もマニュアルを見ないと分からない、キーのストローク回数も多いといった問題があって、最近のデバッガではCUIのない(コマンド入力のできない)もしくは使わないデバッガがほとんどです。

KMCのPARTNERでは、GUIの便利な点とCUIの便利な点を組み合わせて利用できる方法は無いものか？と思案した結果。安直ではありますが、GUIでの動作(ロードやブレーク設定など)をCUIのヒストリとして登録する方法をとっています。

これで、最初のロードは、GUIを使ってマウスでファイル指定してロードし、その後のロードは、'L',SHIFT+↑,Enter の3つのキー操作でリロードできるようになりました。社内の開発スタッフは、みんなこの方法をうまく使っています。

このように、GUIだけにたよらず、CUIを組み合わせて使ってみることも良いのではないでしょうか？

---

参考リンク : PARTNER のデバッグ風景を Flash で見ることができます。

「GUI と CUI の連携」
http://www.kmckk.co.jp/jet/gui_cui.html
「シンボルラインでのシンボル名拡張機能」
http://www.kmckk.co.jp/jet/symbol.html
「関数バックトレースと関数ローカル変数ウィンドウの連動」
http://www.kmckk.co.jp/jet/debugger.html
「モジュールウィンドウからの関数の選択」
http://www.kmckk.co.jp/jet/module.html

こんにちは、若槻です。今回は決意表明もかねて、健康に関する話を書きたいと思います。（公式ブログに書いてしまえば、イヤでも生活改善をやらざるを得ないでしょう… 苦笑。）続きを読む

続きを読む

日本Androidの会の7月のイベントで、日立製作所の川崎さんからAndroidをSHに移植した話がありました。

SuperH アーキテクチャ向けAndroidの開発
続きを読む

KMC は、基本的にはソフトウェアに重点を置く会社です。開発スタッフの多くはソフトウェア技術者です。

しかし、JTAG-ICE デバッガの最下層では、非常にハードウェアに近い技術が必要です。ここら辺は、徐々に若手への技術移転を進めている（進めないといけない）ところなのですが、現在はほぼ CTO と、数人の先輩に強く頼っています。

PARTNER-Jet デバッガが、高速性と高機能を両立できているのは、KMC がソフトウェアとハードウェアの役割分担が上手くできているという点が大きいと思います。ハードの人たちが、非常に高度な JTAG プログラミング技術や、FPGA などのハード的な高速化技術を駆使して、最も負荷がかかる JTAG 通信部分をチューニングしてくれているおかげで、ソフトウェア技術者はあまりパフォーマンスチューニングを意識する必要が無く (もちろん PARTNER-Jet の最大のウリは速度なので、常に速度には神経を使っています)、機能の実装に集中することができるという体制になっているからです。

また、PARTNER デバッガソフトウェアは、25 年以上にも渡りブートストラップ的な開発（デバッガを開発するためには、デバッガが必要という、不思議な循環）を続けてきた結果、非常に独特な内部構造になっています。詳細はもちろん企業秘密なのですが、ちょっと一朝一夕には真似できない、優れた設計になっていると思います。

この独特の設計は、完全に PARTNER (x86 版。今のところは製品としては販売されていない、社内用ツールです) に依存した、PARTNER ありきのものなので、通常のデバッガしか無い状況では、ちょっと実装やデバッグは不可能なのではないかと思います。そしてこの構造こそが、PARTNER のデバッガソフトウェア部分の開発効率が非常に良い（一度理解してしまえば、非常にコードが書きやすい。慣れるまでは大変ですが…）ことの本質となっているのではないかと思います。

続きを読む

このたび社内のプロジェクト管理システムを Trac から Redmine に更新しました。実作業を行った北川先輩から、その時の作業メモをブログのネタとしていただきました。ありがとうございます。

北川さんが作業を行った際、ネット上にまとまった情報が無くて非常に苦労したそうです。この情報が誰かのお役に立てれば幸いです。続きを読む

巷ではプログラマ 35 歳定年説なるものがまことしやかに囁かれているそうです。

私は KMC 以外の会社を知らないのでなんとも言えないのですが、これはどうやら新しいことが覚えられなくなってくるなどの能力的な限界というよりは、単に技術者のキャリアパスが十分に整備されていないため、ある程度以上の年齢で正当な待遇を得るためには、向き不向き関係なく、技術者から管理者に否応なしにシフトせざるをえないという現状に対する嘆きのようです。

一方 KMC 社内を見渡してみると、なんと 35 歳以下の技術者がほとんどいません（笑）社長と CTO が、ともに 50 間近にして現役の技術者です。というよりもむしろ、社内で最も多く、かつ重要なコードを書いているのがこのお二方だと思います。

この間、社内のソースコード管理システムが変わり、社長困ってるんじゃないのかなとひそかに心配していたのですが、全くの杞憂でした。「git 便利やわ〜、ちょっとまだ不安定で master に入れるのが怖い状態の時、ローカルに branch 切って置いておけるもんな」と、普通に使いこなしていました。

組み込み業界はただでさえ年齢層が高めと言われますし、25 年以上の歴史を持つ老舗デバッガベンダーというと、なんとなく保守的なイメージを持たれている方もいるかもしれません。もちろん、これまで積み重ねてきた信頼と実績を守るために、重要な製品コア部分そのものの変更には慎重ですが、それ以外の技術、例えば最近は redmine という Ruby on Rails で組まれたバグトラッキングシステムが運用されていたりと、活発に新しい技術に取り組んでいく風土が社内にあります。

そもそもこのブログ自体が、わりと組み込み業界では珍しい試みなのではないかと思います。非常に狭い業界ですから、社外秘や NDA は当然としても、それ以外にもうっかり書いてしまうとまずいことがたくさんあったりするようです。このブログを始める際、正直不安もありましたが、社長が「失敗を必要以上に恐れていたら、新しいことはできへん」というスタイルなので、だいぶ救われています。

KMC に入社して、初めて JTAG-ICE デバッガを触った時は感動しました。(と言っても、わずか半年ほど前なのですが。)

それまで私は PC の世界しか知らなかったので、いきなり CPU (たしか、たまたま社長の手元にあった MIPS ボード ?) が剥き出しの基板を渡されても、「これで一体何をどうすれば良いのだろうか…」と戸惑ってしまいました。

PC の上でプログラムを書いていた時、いかに自分が分厚く抽象化された世界の上で生きていたのかということを実感させられます。シェルはもちろん、OS も何も無い世界。当然ディスプレイもマウスもキーボードも、つながるインタフェースすらありませんし、唯一存在している NIC も、ドライバが無いのでそんなに簡単には動かせません。はてさてどうしたものか。

すると社長が慣れた手つきで、ささっと JTAG コネクタにケーブルを指して、JET と PC をつないでデバッガを起動してくれました。PARTNER デバッガは ELF を理解するので、GCC などのクロスコンパイラが生成した実行ファイルをそのままロードできるのですが、これだけでも驚きました。そしてそのままステップ実行できる。全てのメモリが見える。レジスタの値も何もかも自由に変えられる。すごいと思いました。

次に感動したのは、シリアルコンソールがつながった時でした。もちろんシリアルコンソールなんて使ったのは初めてでした。最終的には、最も素朴なメモリマップト I/O を叩くわけで、printf とかも最終的にはこういう風なところに落ちるんだなぁと、もちろんそれまで知識は多少あったわけですが、やはり実際に経験してみたことにより、ふっと腑に落ちてつながる感覚がありました。

プログラミングの入門書の一番最初の例題である printf が出るまでには、シェルが動いてローダが動いて OS が動いてドライバが動いて… 数え切れない抽象化層を経由して、GUI が作り出した仮想のコンソールの上に文字が出るわけです。

そういう抽象化層を全て取っ払った世界にいきなり入ることが出来る。やはり JTAG-ICE デバッガの感動は、実際に味わってみるのが一番ではないかと思います。組み込み業界の社会人だけではなく、むしろ学生さんにこそデバッガ使って欲しいなと思ったりもします。CPU を身近に感じられ、教育用にも最高なのではないかと思います。

この直接 CPU を操作できるという JTAG-ICE デバッガのメリットは、開発や教育だけでは無く、実は意外なことに、CPU シミュレータ作成においても大変魅力的だと私は個人的に思っています。

CPU のシミュレータだけ作っても、基本的には何もできません。I/O メモリを実装して、割り込みが動くようにして、シリアルコントローラや NIC などの仮想ハードウェアエミュレーションを実装して、プログラムをロードするしくみを作って… 実際に、QEMU などのエミュレータでは、自前の ELF ローダや、I/O デバイスや UI という、ある意味では非本質的な部分に非常に多くの労力が割かれています。

デバッガがあれば、CPU とデバッガをつなぐ部分 (デバッガにレジスタやメモリの値を渡す通信のしくみ。簡略化された JTAG インタファースを、ソフトウェア的に実装するようなイメージ) さえ実装すれば、あとは PARTNER デバッガソフトウェアの汎用的なしくみをそのまままるごと利用することができます。ローダなどの再実装は不要で、いきなり ELF をシミュレータのメモリにロードして実行することができます。OS もシェルも何も動いていなくても、PARTNER のマクロ機能を使えば、様々なテストが自動化可能です。

私は今、PARTNER に直接つながるシミュレータを研究開発しているわけですが、自分で書いた（と言っても、基本部分を社長が既に実装したものを引きついだのですが） ARM シミュレータに PARTNER がつながって、実機と同様に動いてデバッグできるというのは、ものすごく楽しくてうれしいものです。このシミュレータの上で、これまた自分で移植した Linux が動いた時が、第三の感動でした。

PARTNER-Jet には、イベントトラッカーという機能が標準で搭載されています。

http://www.kmckk.co.jp/event_tracker/index.html

イベントというと何やら難しそうですが、ここでいうイベントとは「ターゲットプログラムの実行中に、なんらかの変化が起こった」ということを指します。例えば OS のタスク切り替えや、OS が無い場合は pc が特定のアドレスに来た場合など、任意の状態変化をイベントとしてユーザ定義することができます。

イベントトラッカーは、メモリに記録したログデータをグラフィカルに表示・解析するための汎用的なしくみを提供します。

組み込みソフトウェア開発で printf デバッグができるのは、けっこう恵まれた状況です。開発初期はシリアルコンソールすらつながっておらず、一切の I/O が使えない状況がけっこうあります。

PARTNER-Jet のような JTAG-ICE デバッガを使えば、そのような状況でも、とりあえずステップ実行をしてプログラムの動きを追うことができます。しかし、割り込み処理など、タイミングが重要なプログラムをデバッグする際には、これだけでは厳しいです。

PARTNER-Jet には、VLINK という、ターゲット上で動くプログラムから直接デバッガに printf などで出力できるという機能もあるのですが、そもそも printf 自体が比較的重い処理となるため、RTOS などのイベントハンドラの中で呼ぶことは厳しいですし、printf を呼ぶとタイミングが狂って再現しなくなってしまうバグなどもありがちです。

このような場合、イベントトラッカーが威力を発揮します。イベントトラッカーは、JTAG がつながって、メモリの読み書きができて、ログ用のバッファが確保できる状況ならば使えます。しくみが単純で処理が軽いぶん、様々な場面に使える、非常に一般的なデバッグ手法と言えます。

OS を使う場合は、Linux や各種 RTOS (T-Kernel や Toppers) など、それぞれの OS ごとに KMC が提供するパッチを当てることにより、プロセスの切り替えなどのタイミングを詳細に記録することができます。

OS が無い場合は、直接 KMC が提供するヘッダとソースコードをプロジェクトに組み込み、初期化関数を読んだ後、任意のタイミングでイベント発行関数(引数に与えられた整数がイベントとして記録されます)を呼ぶことで、イベントログを取ることができます。1 ヘッダと 1 ファイルのみなので、カスタマイズも簡単にできます。

イベントトラッカーがやっていること自体は特別なことではなく、多かれ少なかれ、どこの組み込み開発でもアドホックに行われていることだと思います。しかし、デバッガと連携した汎用のしくみが最初から提供されることにより、CPU 占有時間の計算やイベントの抽出・マスク機能など、高度な表示や統計・解析機能が簡便に使えるようになり、工数が削減できます。また、しくみが共通化されることにより、デバッグの属人性が薄まり、ノウハウの共通化が可能になるため、開発そのものだけではなく、技術教育面などにも恩恵があると考えられます。

皆さん、こんにちは。KMCの辻です。

さて、今日はPARTNER-Jet ver5.6に搭載した新しい機能「スナップショットデバッガ」についてお話します。

PARTNER-Jet ver5.6は、つい先日に僕たちがリリースした、新バージョンデバッガです。この新バージョンデバッガには、新たに「スナップショットデバッガ」という機能を追加しました。

このスナップショットデバッガを一口で説明すると、「コアダンプのCPU版」という感じでしょうか。UNIX上でのcoreファイルを使ったデバッグに似ています。PARTNER-Jetを使ってターゲットボードのソフトウェアをデバッグしている時に、デバッガ上からスナップショットを作成します。その後は、作成したスナップショットファイルを用いて、ターゲットボードなしにオフラインでデバッグを行う、という機能です。オフラインでのデバッグになるので、CPUの実行に関する事はできませんが、その他のデバッガの機能はほぼ全て利用可能です。

スナップショットファイルには、それを作成した時点でのメモリの内容とCPUの汎用レジスタや制御レジスタの情報などのほかに、PARTNER-Jetで採取していたETMやAUDなどの実行トレースの内容も保存しています。トレースデータを参照すれば、そこに至る過程も調べる事もできます。

私的な話になりますが、僕はその昔に通信機器のOSの開発をしていた事があります。電話網に使われる通信機器ですので、耐障害性など品質については厳しく”全てのバグを取り除く”という意識でのソフトウェア開発でした。しかし、難解なバグや再現性の低いバグも多く、そのようなバグ調査に実機を長時間占有させておくことも難しい事も事実でした。そのような状況でも、障害発生時に保存した実機のメモリを、ワークステーション上で解析をしてバグ対策を行っていました。また、同じ問題を一人ではなく複数人で解析したり、ファイルを転送して離れた場所の人と一緒に解析したりしていました。当時は物理メモリのファイルと、そしてシンボルデータをつき合わせて、構造体などをメモ書きしながら解析をしていました。

もちろん、このスナップショットデバッガを利用すれば、より快適にこのような作業を行うことができます（当時は本当に根性デバッグで大変でした）。

これからは、問題が発生した時には、スナップショットを保存しておくのはどうでしょうか？