2009年07月02日
開発メンバーの新人、若槻です。
去年の 11 月から、京都マイクロコンピュータ株式会社という、デバッガを作っている会社で働いています。
デバッガというと地味な感じがするかもしれませんが、本来ソフトウェア開発には無くてはならないものです。ところが残念なことに、プログラミングの教科書などでは、デバッガは全く触れられないか、非常にあっさりとした扱いで終わることがほとんどだと思います。また、初心者のうちからデバッガに頼ることを覚えてしまうと、ちゃんと脳内でプログラムの動きを想像して机上デバッグする癖がつかないので邪道だ、というような主張をする人もたまに見かけます。
そういう私も、この会社に入るまでは、それほどデバッガの必要性を感じていませんでした。しかし、今ではデバッガ無しでプログラムを書くことは大変もどかしく、苦痛に感じます。例えばよくある状況として、変数の値がおかしくなっているようだが、この変数への変更はどこで行われているのか調べたい、という状況があると思います。これをデバッガ無しで調べようと思ったら、ソースコードを隅々まで見なければいけないのでかなり大変 (見逃す可能性も高い) ですが、デバッガがあればデータブレーク機能 (特定番地のメモリの読み書きが発生した瞬間に止まる) で一発です。
デバッガ無しでプログラムを書くということは、例えるならば、CT や MRI などの最新医療機器を使わずに診察を行うことと同じように思えます。もちろん基本技術をきちんと習得することは重要ですし、問診や想像力を駆使し、聴診器一つ (printf デバッグ) で病気を診断するベテラン医師の能力は素晴らしいものですが、やはり直接内部を見ることができる確実性には代えられません。
私が会社に入ってすぐに先輩たちに言われて、いまでも強く印象に残っているのですが「仮説は重要だが、仮説はあくまでも仮説であって、(特に組み込み業界では)実際に動いているものだけが真実。プログラム上のロジックがいくら正しくても、もしかしたらハードウェアにバグがあるかもしれない。」という教訓があります。いくら仮説の上に仮説を積み重ねていっても、いつまでたっても砂上の楼閣です。デバッグの際には、確実性をコツコツと積み上げていくことが何よりも重要です。これもまた最近辻先輩に言われたことですが「デバッグとは怪しいところを闇雲に探すことではなく、確実なところを探すことだ。」至言だと思います。
また、デバッガは、バグを発見するためだけではなく、ソースコードを理解する際にも非常に有益です。GCC や Linux のように、大量の ifdef でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。
先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ（開発）の魅力を伝えていくことができたら良いなと思います。
去年の 11 月から、京都マイクロコンピュータ株式会社という、デバッガを作っている会社で働いています。
デバッガというと地味な感じがするかもしれませんが、本来ソフトウェア開発には無くてはならないものです。ところが残念なことに、プログラミングの教科書などでは、デバッガは全く触れられないか、非常にあっさりとした扱いで終わることがほとんどだと思います。また、初心者のうちからデバッガに頼ることを覚えてしまうと、ちゃんと脳内でプログラムの動きを想像して机上デバッグする癖がつかないので邪道だ、というような主張をする人もたまに見かけます。
そういう私も、この会社に入るまでは、それほどデバッガの必要性を感じていませんでした。しかし、今ではデバッガ無しでプログラムを書くことは大変もどかしく、苦痛に感じます。例えばよくある状況として、変数の値がおかしくなっているようだが、この変数への変更はどこで行われているのか調べたい、という状況があると思います。これをデバッガ無しで調べようと思ったら、ソースコードを隅々まで見なければいけないのでかなり大変 (見逃す可能性も高い) ですが、デバッガがあればデータブレーク機能 (特定番地のメモリの読み書きが発生した瞬間に止まる) で一発です。
デバッガ無しでプログラムを書くということは、例えるならば、CT や MRI などの最新医療機器を使わずに診察を行うことと同じように思えます。もちろん基本技術をきちんと習得することは重要ですし、問診や想像力を駆使し、聴診器一つ (printf デバッグ) で病気を診断するベテラン医師の能力は素晴らしいものですが、やはり直接内部を見ることができる確実性には代えられません。
私が会社に入ってすぐに先輩たちに言われて、いまでも強く印象に残っているのですが「仮説は重要だが、仮説はあくまでも仮説であって、(特に組み込み業界では)実際に動いているものだけが真実。プログラム上のロジックがいくら正しくても、もしかしたらハードウェアにバグがあるかもしれない。」という教訓があります。いくら仮説の上に仮説を積み重ねていっても、いつまでたっても砂上の楼閣です。デバッグの際には、確実性をコツコツと積み上げていくことが何よりも重要です。これもまた最近辻先輩に言われたことですが「デバッグとは怪しいところを闇雲に探すことではなく、確実なところを探すことだ。」至言だと思います。
また、デバッガは、バグを発見するためだけではなく、ソースコードを理解する際にも非常に有益です。GCC や Linux のように、大量の ifdef でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。
先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ（開発）の魅力を伝えていくことができたら良いなと思います。
2009年07月01日
以前少しはまってしまったのですが、Linux kernel 2.6.29 は、gcc 4.1.[01] ではコンパイルできなくなったようです。
エラーメッセージを頼りに linux-2.6.29/include/compiler-gcc4.h を見てみると、なるほど。
どうやらミスコンパイルが起こるので、はじかれているようです。
この時に入ったようですね。
http://kerneltrap.org/mailarchive/git-commits-head/2009/1/2/4576264/thread
Linux Kernel 2.6.28 のリリースが 2008 年 12 月で、2.6.29 のリリースが 2009 年 3 月ですから、その間に入った変更のようです。
エラーメッセージを頼りに linux-2.6.29/include/compiler-gcc4.h を見てみると、なるほど。
/* GCC 4.1.[01] miscompiles __weak */
#if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
# error Your version of gcc miscompiles the __weak directive
#endif
どうやらミスコンパイルが起こるので、はじかれているようです。
この時に入ったようですね。
http://kerneltrap.org/mailarchive/git-commits-head/2009/1/2/4576264/thread
Linux Kernel 2.6.28 のリリースが 2008 年 12 月で、2.6.29 のリリースが 2009 年 3 月ですから、その間に入った変更のようです。
2009年07月01日
blog.kmckk.comを訪問してくださった皆さま。
こんにちは、はじめまして。京都マイクロコンピュータの辻です。
この度、僕たち京都マイクロコンピュータ(KMC)でも、BLOGを利用してメッセージ発信をして行こう、という事になりました。
皆さま、今後ともよろしくお付き合いください。
このBLOGでは、製品に関する技術・サポート情報なども取り扱いますが、直接に製品とは関係のない色々な事を取り上げていくつもりです。
このBLOGですが、訪問して頂いた皆さまと共に成長していきたいと思っておりますので、コメントなどもよろしくお願いいたします。
2009年7月1日
京都マイクロコンピュータ株式会社
スタッフ一同
こんにちは、はじめまして。京都マイクロコンピュータの辻です。
この度、僕たち京都マイクロコンピュータ(KMC)でも、BLOGを利用してメッセージ発信をして行こう、という事になりました。
皆さま、今後ともよろしくお付き合いください。
このBLOGでは、製品に関する技術・サポート情報なども取り扱いますが、直接に製品とは関係のない色々な事を取り上げていくつもりです。
このBLOGですが、訪問して頂いた皆さまと共に成長していきたいと思っておりますので、コメントなどもよろしくお願いいたします。
2009年7月1日
京都マイクロコンピュータ株式会社
スタッフ一同
