gdbserverは，non-stop modeをサポートしない．

お仕事 下ネタ(したネタ) 
GNU gdb (GDB) 6.8.50.20090203-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) set target-async 1
(gdb) set non-stop 1
(gdb) set debug remote
Argument required (integer to set it to.).
(gdb) set debug remote 1
(gdb) target remote localhost:12345
Remote debugging using localhost:12345
Sending packet: $qSupported#37...Ack
Packet received: PacketSize=3fff;QPassSignals+;qXfer:libraries:read+;qXfer:auxv:read+;qXfer:features:read+;QStartNoAckMode+;qXfer:osdata:read+
Packet qSupported (supported-packets) is supported
Sending packet: $QStartNoAckMode#b0...Ack
Packet received: OK
Sending packet: $Hg0#df...Packet received: OK
Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Packet received: l<target><architecture>i386</architecture></target>
Non-stop mode requested, but remote does not support non-stop
(gdb)

ぷぎゃ．


x86のLinuxだからかなー，組込みでもホスト環境でこなしちゃうだろうからなー．

と思って，src/gdb/gdbserver/ を探ってみたけれど，どこにも QNonStopの文字列が無い．


まじですか? 組込みLinuxの人たちは，どうやってマルチスレッドアプリのデバッグをしているのですか? まさか，printfですか? きょうびITRON屋でもprintfデバッグはしませんぜ．
ITRONよりも開発環境が整っているというのは，組込みLinuxベンダの常套句だと思うのですけれどね．現実は，こんなものですか．

まあ，今回の調査の目的は，GDBの挙動をみること．組込みLinuxのアプリ屋さんたちが，どんなに劣悪な環境下で開発していようが知ったことではないのですけれども．

ラガード化しつつあるSI，まだヒヨッコなET．

ひがやすをBlogを読むたびに，SI (System Integration) とET (Embedded Technology)の違いを痛感するのだけれど，なんでだろ．

進化しないオープンソースがあったって別に変ではない．が

というか私が関与しまくった TOPPERS/JSP は公式見解として進化を止める(保守モードに入れる)と宣言されていたりするので，変だと言われたら立つ瀬が無い．

でも，↓これは違うなー．


ユーザは、安定性を求めるものです。特にマジョリティーな人たちはそう。

例: ETにおける GDB の恩恵

先程別のエントリとして書いたGDBのnon-stop mode．こいつのサポートは，表向きはマルチスレッドアプリのデバッグ向上なのだけれど，実際には， JTAGデバッガとの擦り合わせという側面も強い．つまりET向けの機能拡張．機能強化が行われた時期が expat (XML)サポートとか，スタブからのメモリマップ情報の提供とかと近いのが，その証拠．フラッシュROMの番地なんて，IT系では絶対に要らない．

GDBのリモートプロトコルは，そこそこ高価なJTAG ICEでも何らかのサポートが期待できる，事実上の標準的な位置にある．音楽業界でいうMIDIみたいな感じ．
しかしながら，ほんの1，2年前のGDBでは，{デバッガベンダが売り込みたい|ユーザが使いたい}機能をサポートしきれなかった．JTAGデバッガはon-the-fly でメモリやレジスタを見られることが当たり前だし，フラッシュROMの番地に書けば，透過的に書込んでくれるのも当たり前だが，Unix系でぬくぬく育ったGDBにはそんな機能は無かった．

さて，フラッシュROMに書込める機能は，ETにおいてマイノリティだろうか．non-stopデバッグは? もちろん，否．

マジョリティが安定を求めるわけではない．

とはいえ，GDBが常に馬車馬のように進化を続けたというわけでもなく，1990年代後半には更新が停滞した時期もある．その後Linuxバブルがあって相対的に停滞感があるように見えるとか，その諸々，様々な要因があるが，当時のPOSIX用のデバッガとしては完成の域に近づいていたとも言えるのかもしれない．


good enough になったドメインでは，安定が求められる傾向にある，ということだろう．
先の引用を書き換えるとするならば，こんな感じ．

ユーザは，機能が十分になったら安定性を求めるものです．

もしくは

ユーザは，機能が十分になるまで，機能も安定性*1も求めるものです．

てなかんじ．


別の角度から言い替える．機能が十分かどうかについて議論を省略できるということは，"顧客は機能が十分であると間違いなく言う(新しいテクノロジに興味が無い)と看做している"と考えることもできる．

SIerの現在をキャズム理論に当てはめてみる．

技術マーケティングの世界には，キャズム理論という定番の理論がある．テクノロジーには寿命がありそれぞれの段階で付く顧客が違うというのが，そこでは論じられている．
細かい話は，下記の蛇足を参照して頂くとして，一気に持論を展開する(強引)．
キャズム理論に当てはめると，SIerという業界は，レイトマジョリティからラガードへ支配が移る段階にあるのだろう．

そのことは，ひが氏のエントリで引用されているコメント，またエントリへのトラバの記述からも伺える．

開発者としては、冒険する、というか、最新技術に取り組んでいくということは理想ですが、現実的には、業務では実績のある枯れた技術が採用される傾向が強いように思います。


いったいいつから冒険しなくなったのだろうか。
もうJavaSE6ですら2年以上がたち、J2SE5.0はすでに4年以上でしかもEOL移行期間にはいっている。それなのにいまだにJavaは1.4だとかいうこともある。

おかしい。10年前のSI業界はそんなことはなかったはずだ。

SIer は終焉の段階にある? その先は?

キャズム理論では，ラガードは儲けの対象ではなく，そこに至ったテクノロジーは終焉を迎えるという．
IT業界が抱えているらしい閉塞感は，自らのテクノロジーライフサイクルが，終焉に近づいていることを肌で感じ取っていることが影響しているのではないだろうか．


キャズム理論では，テクノロジーライフサイクルが終わってしまった後のことは残念ながら論じられていない．
ラガードに行く前に河岸を替えて生き残る方法については，クリステンセンという人が書いた「イノベーションのジレンマ」という本が有名．まあ内容を端的に言うと「一度成功しちゃうと，新しいことをやる舵を切れなくなって失敗しちゃうんだよね」というミもフタもない話*2．
まあ敢えて弄らない勇気，みたいなものはソフトウェア開発にとっては必要な場面があることはあるのですが…


ユーザは、安定性を求めるものです。特にマジョリティーな人たちはそう。
破壊的イノベーションの余地も残しておかないと，終わっちゃうよー，とかとか．

蛇足

キャズム理論を知らないITエンジニアは少なくない(だってマーケティング論だし)と思うので，蛇足しておく．

レイトマジョリティ(保守派)については，こんな風に分析されている．

保守派はハイテク製品そのものには関心はなく，大きな利益幅は期待できない．しかしその購買層の大きさゆえに，適切な方法で保守派に接するベンダーには大きな利益がもたらされる．

モロに1980-2000年代のSIerのお客様がたですなぁ．

ラガードについては，こんな感じ．

つまり，ラガードを追い求めてみても販売にはつながらないということだ．

もうちょっと知りたい方は，引用元の書籍をどうぞ．

キャズム

キャズム

*1:ちなみにGCCやGDBなんてバイナリでしかインストールしないよ，という人のために補足しておくと，GDBはGCCやLinuxカーネルなどに比べると厳しい警告チェックやリグレッションテストが行われている．安定性は求められていると看做せる．デバッガのデバッグってほんとに辛いのよ．

*2:一応，それを避ける方法の考察も，続編には書いてあります．