トップ «前の日記(2008-09-27) 最新 次の日記(2008-09-30)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|

ToDo:


2008-09-29

_ だるい

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

有意義なことと言えば 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)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2008年
9月
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
1.niha(2014-05-24 05:24) 2.hi_saito(2014-05-24 05:24) 3.ku-ma-me(2014-05-24 05:24)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h