はじめてのにき

_ だるい

今日も無為な一日だった…

有意義なことと言えば hogelog さんの tumblr とそこからのリンクをだらだら読みあさってたというような。

少女ギターを弾くが出てきた。 あれはすばらしい。 つゆダクとか早く終われと思ってたけど今どうなったんだろう。 なんか違うのをまたスピリッツでやってるらしい…

(00:29)

_ DOS

ゴルフ場に入れた。

http://golf.shinh.org/p.rb?FizzBuzz#DOS

適当だけど終了処理入れても 79B だから勝ってるとは思う…

http://labs.cybozu.co.jp/blog/takesako/2007/05/fizzbuzz_x86.html

まぁ DOS っていうか COM って Windows でも Linux でも手軽に書けすし手軽に走るし、 アセンブリ入門には良い気がするなぁ。

(02:04)

_ 最適化オプション

で -Wall の挙動が変わるとかは知っといて損はない気がする。

i@u4 ~/test
> cat unused.c
int main() {
    int a;
    return a;
}
i@u4 ~/test
> gcc unused.c -Wall
i@u4 ~/test
> gcc unused.c -Wall -O2
unused.c: In function 'main':
unused.c:3: warning: 'a' is used uninitialized in this function

http://d.hatena.ne.jp/hyoshiok/20080927#p2

via http://homepage1.nifty.com/herumi/diary/latest.html#28

本題については2種類うんぬんについては

管理すべき実体が増えることは管理のコストが増加して、よろしくない。最適化オプシ
ョンなしのバイナリで延々デバッグしていたのだが、実は最適化オプションありのバイ
ナリでは当該バグに遭遇しないとか

のあたりはギャグで言ってるのかなぁ的なレベルだなぁ… 話が逆でターゲットが組み込みとかならコンパイラのバグ回避とか あると思うけど…

(02:40)

_ 全然適切な例が思いつかんけど

static inline void f(int i) {
    int* p = 0;
    int j ;
    for (j = 0; j < i; j++) {
        p += j;
    }
    for (j = 0; j < i; j++) {
        *p += j;
    }
    for (j = 0; j < i; j++) {
        p += j;
    }
}

int main() {
    f(10);
}

この程度の関数が inline 展開で消え失せたりして、

(gdb) run
Starting program: /home/i/test/a.out

Program received signal SIGSEGV, Segmentation fault.
main () at hard_to_debug.c:15
15      int main() {
(gdb) bt
#0  main () at hard_to_debug.c:15

とか言われたら結構キツいというか 場合によってはデバッグビルドしなおして gdb で追う方が速いとか言いたいんだけど、 例があんまり適切じゃないからイマイチ。

まぁ僕も gdb 使うとしても たいていは最適化ついたままでやってるし、 たいていのケースで慣れりゃデバッグできるよ〜的な 主張はわかるんだけども。

それはそうと、最近よく妄想するのは、 最適化とか strip かかったバイナリの行を推測するようなツール。 strip されててもその関数のダンプと関数内の落ちた位置を 人間が見たらだいたいどこで死んだかわかるよね。 そういうカンをある程度自動化できないかなぁ的な。

あとスタックトレースって その関数の何分の何まで進んだかとか表示してくれると 上記のような推測がしやすくなるんだけどなぁとかいう。 まぁ分岐あると推測外したりしまくりそうだけど。

(03:00)

_ T9

http://ja.wikipedia.org/wiki/T9

おおー。子音入力をだれか

(04:17)