とあるエンジニアの備忘log: C

ラベル C の投稿を表示しています。すべての投稿を表示

2013年1月20日日曜日

Shared Object 入門

最近の gcc だとシンボル解決がうまくいかないといかないことがあったので、ちょっと調べました。

次のような 3つのソースファイルがあったとして、ダイナミックリンクで作ってみましょう。

`main.c`

int foo(void);
    int main(void)
    {
            return foo() + 1;
    }

`foo.c`

int bar(void);
    int foo(void)
    {
            return bar() + 1;
    }

`bar.c`

int bar(void)
    {
            return 0;
    }

shared object を作るのに必要なのは、コンパイル時に `-fPIC` オプションをつけることと、リンク時に `-shared` オプションをつけることの 2点です。

$ gcc -fPIC -c -o bar.o bar.c
    $ gcc -shared -o libbar.so bar.o

のように中間オブジェクト `bar.o` を作ってもいいですし

$ gcc -shared -fPIC -o libbar.so bar.c

のように一度にやってもよいです。いずれにせよ `libbar.so` が作られます。

では、最後までやってみます。

$ gcc -shared -fPIC -o libbar.so bar.c
    $ gcc -shared -fPIC -o libfoo.so foo.c
    $ gcc -L . -lfoo -lbar main.c
    /tmp/ccqQv8uv.o: In function `main':
    main.c:(.text+0x5): undefined reference to `foo'
    collect2: ld returned 1 exit status

あれれ、 `foo` が見つからないと言われました。。。
gcc のバージョンによっては、上記のやり方でもエラーなしにリンクできる場合もあるかもしれません。
gcc のバージョンが新しいとうまくいかないようです。
私の手元の gcc のバージョンは 4.6.3 です。

ちなみに、

$ gcc -L . main.c -lfoo -lbar

のようにすればうまくいきました。

関数が `main()` ->　`foo()` -> `bar()` のようにコールしているならば、
リンク時にも `main.c -lfoo -lbar` の順に並べないと、リンク解決できないようです。

とは言うものの、リンク時に順番をいちいち考えるのも面倒です。

順番を気にせずうまくやってくれるためには、リンカーに、 `-no-as-needed` を渡せばよいようです。

$ gcc -Wl,-no-as-needed -L. -lfoo -lbar main.c

でも

$ gcc -Wl,-no-as-needed -L. -lfoo main.c -lbar

でもうまくいきます。

実行してみます。
`libfoo.so` と `libbar.so` は検索パスに置いてないので、 `LD_LIBRARY_PATH` を指定します。

$ LD_LIBRARY_PATH=$PWD ./a.out
    $ echo $?
    2

うまくいきました。

ちなみに、リンク時に `-R`  または `-rpath` でライブラリ検索パスを指定しておけば、実行時に `LD_LIBRARY_PATH` は指定しなくてもいいです。

$ gcc -Wl,-no-as-needed -Wl,-R$PWD -L . -lfoo -lbar main.c

または

$ gcc -Wl,-no-as-needed -Wl,-rpath $PWD -L . -lfoo -lbar main.c

まだよくない点があります。

関数 `main()` から直接的にコールしているのは `foo()` だけであって、 `bar()` を直接的にコールしているわけではないです。

なので、関数 `foo()` をコールするために

$ gcc -Wl,-no-as-needed -L. -lfoo -lbar main.c

のように `-lfoo` も `-lbar` もリンクしないといけないのは変な話です。

関数 `foo()` は関数 `bar()` をコールしているので、 `libfoo.so` は `libbar.so` に依存していることになります。

そこで、shared object 間の依存関係を考慮することにします。

`libfoo.so` を作るときにも `-Wl,-no-as-needed` を指定すればうまくいきます。

$ gcc -shared -fPIC -o libbar.so bar.c
    $ gcc -shared -fPIC -Wl,-no-as-needed -L . -lbar -o libfoo.so foo.c
    $ gcc -Wl,-no-as-needed -Wl,-rpath $PWD -Wl,-rpath-link $PWD -L . -lfoo main.c

最終行で、 `-lbar` は不要になっています。 ただし、 `-rpath-link` オプションがいります。

`ldd` コマンドで依存関係を見ると、 libfoo.so は libbar.so を必要としています。

$ ldd libfoo.so
     linux-vdso.so.1 =>  (0x00007fff1fbff000)
     libbar.so => not found
     libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5141d0d000)
     /lib64/ld-linux-x86-64.so.2 (0x00007f51422ea000)

ちなみに、shared object の勉強は
[共有ライブラリーを解剖する](http://www.ibm.com/developerworks/jp/linux/library/l-shlibs/)
というページがわかりやすかったです。

2012年8月4日土曜日

インライン関数まとめ

インライン関数についてややこしいところをまとめておきます。
結論から言うと、常に `static inline` を使え、ってことになります。

結果だけ知りたい人は以下は読む必要なし。

### 最初に ###

`inline` キーワードは関数callを高速化せよ、という指定であって、`inline` を付けたからといって、本当にインライン展開されるかはわかりません。

実際のところ、最適化オプションをつけていない場合、`inline` を付けても、一切インライン展開してくれません。
最適化オプションによらず、インライン展開を強制させるには `__attribute__((always_inline))` をつけるというやり方があります。

`-O1` オプションをつけた場合、明示的に `inline` がついている場合はなるべくインライン展開しようとするが、`inline`指定がないものについては インライン展開しないようだ。

`-O2` オプションをつけた場合、`inline`指定がなくても、インライン展開をする場合がある。static 関数や、非常に短い関数など。

続いて重要なのは、インライン展開された結果、展開された関数の定義コードが残るのか、消えるのかという点について。
ここを間違えると、リンク時に関数の多重定義でエラーになったり、逆に関数が未定義でエラーになったりします。

これについては [gcc のマニュアル](http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Inline.html)に説明があるので、ほとんどここに書いてあるとおりなのですが。

`-std=` の指定によって挙動が違ってくる部分もあるのだが、まず全体通して共通している部分から。

### ケース1 ###

static inline int inc(int *a)
    {
      return (*a)++;
    }

のように static 関数に `inline` がついた場合。
この場合、（`static inline` の方が static よりもスピード重視であることを除き）基本的に `inline` を付けなかった時と同じ扱いになる。

どういうことかと言うと、すべての関数 call がインライン展開されたときは関数定義は残らない。
インライン展開されないcall があったり、関数のアドレス参照があったりすると関数の定義は残ります。

ちなみに、以下のように `inline` をつけずに、`__attribute__((always_inline))`をつけ、最適化オプションなしでコンパイルした場合、インライン展開はされたが、関数定義は残った。普通はこういう使い方はしないだろうが。。

static int __attribute__((always_inline)) inc(int *a)
    {
      return (*a)++;
    }

### ケース2 ###

extern int inc(int *a);
    
    inline int inc(int *a)
    {
      return (*a)++;
    }

のように、 `inline` なしで宣言された後、 `inline` 付きで定義された場合。
（この例では、宣言の直後に定義を書いているが、普通は宣言の部分はヘッダーに書くはずです。）
この時も `inline` がなかった時と同じような挙動になる。
すべての関数callがインライン展開されたとしても、必ず関数定義は残る。

ここからは `-std=` の指定によって挙動が異なる。

### ケース3 ###

inline int inc(int *a)
    {
      return (*a)++;
    }

のように宣言はなくて、 `inline` 付きで定義された場合。
もしくは、宣言と定義ともに `inline` が付いている時。

`-std=gnu90` (gnu89) または `-fgnu89-inline` を指定しているときは
すべての関数callがインライン展開されたとしても、他のファイルからの関数callに備えて、関数定義は残ります。

一方、`-std=gnu99` または `-std=c99` が指定された時は、全く逆で、この関数定義はインライン展開用にしか使われません。そのため、`inline` 指定の関数定義は必ず消える。
最適化オプションをつけていないときはインライン展開されていないにも関わらず、関数定義は消えてしまう。

ちなみに、`-std=c90` のときは `inline` キーワードを認識しません。

これを書いている時点 (gcc version 4.7) では `-std=gnu90` がデフォルトです。
将来的には `-std=gnu99` がデフォルトになるそうですが。

### ケース4 ###

extern inline int inc(int *a)
    {
      return (*a)++;
    }

のように `extern` と `inline` が同時に指定された場合。

`-std=gnu90` (gnu89) または `-fgnu89-inline` の時は、この関数定義はインライン展開のみに使われ、関数定義は残らない。

`-std=gnu99` または `-std=c99` の時は、関数定義が必ず残る。

### まとめ ###

デフォルト (`-std=gnu90`)では、以下のような挙動になる。

1. `static inline`

すべての関数call がインライン展開されると関数定義が消える

2. `inline` なしの宣言 + `inline` 付きの定義

関数定義は必ず残る

3. `inline`

関数定義は必ず残る

4. `extern inline`

関数定義は必ず消える。

ただし、 `-std=gnu99` または `-std=c99` オプションをつけると 3 と 4 の扱いが逆転します。

以上のことからわかるように、ヘッダーファイルに書いてマクロ関数の代わりにできるのは 1 と 4 です。
2 と 3 はヘッダーに書いてしまうと、(そのヘッダーが複数のファイルからインクルードされていると）multiple definition でエラーになります。

1 をヘッダーに記述し、複数のソースからインクルードさせる場合、 -O1 以上の最適化オプションか、`__attribute__((always_inline))` が必要。
そうしないと、やはり関数の multiple definition でリンクエラーになる。

4 の使い方としてはヘッダーファイルにインライン展開用のコードを書いておき、一つのCソースに、インライン展開されなかった時用の定義を(extern inline を外して)書いておく。
ただし、記述が重複する上に、 `-std=` オプションによって挙動が逆転するので使いにくいです。

以上のことから、 1 が最も使い勝手がよく、インライン関数は `static inline` を使え、ということになります。

Linux Kernelのコードをみてもほとんど `static inline` になっています。
たまに `extern inline` がありますが。。。

2012年6月19日火曜日

マクロを文字列化する

プリプロセッサでマクロを文字列化する方法ないかな〜、って以前から思ってたんですが、 u-boot のソースコード読んでいたときに発見しました！

どういうことかといいますと #x のような文字列化機能がプリプロセッサにありますね。
例えば、以下のような感じ。

---

#include <stdio.h>

#define MK_STR(x) #x

char buf[] = "baudrate=" MK_STR(19200);

int main()
{
puts(buf);

return 0;
}

---

これをコンパイル、実行すると

$ ./a.out 

baudrate=19200

19200 → "19200" のように文字列化してくれています。ここまで普通です。

やりたいことは、19200 の部分をマクロで定義しておきたいのです。

---

#include <stdio.h>

#define CONFIG_BAUDRATE 19200
#define MK_STR(x) #x

char buf[] = "baudrate=" MK_STR(CONFIG_BAUDRATE);

int main()
{
puts(buf);

return 0;
}

---

$ ./a.out 

baudrate=CONFIG_BAUDRATE

う〜ん、残念。
CONFIG_BUADRATE → 19200 → "19200"
と置き換えてほしいんですが、 CONFIG_BAUDRATE をそのまま文字列化してくれました。

sprintf(buf, "%d", CONFIG_BAUDRATE)
みたいに sprintf は使いたくない。

で、今回見つけたやり方は以下の方法。

---

#include <stdio.h>

#define CONFIG_BAUDRATE 19200
#define XMK_STR(x) #x
#define MK_STR(x) XMK_STR(x)

char buf[] = "baudrate=" MK_STR(CONFIG_BAUDRATE);

int main()
{
puts(buf);

return 0;
}

---

$ ./a.out
baudrate=19200

おぉぉ〜！うまくいった。

一見無駄にも見える

#define XMK_STR(x) #x

#define MK_STR(x) XMK_STR(x)

というマクロ定義ですが、こんな効能があるんですね。

2012年4月6日金曜日

拡張インラインアセンブラの勉強 2

[前回](/2012/04/1.html)、破壊レジスタを指定して、どういうコードが生成されるか実験してみた。

破壊レジスタに `"memory"` も指定できるが、この使い方がさらにわかりにくい。

そこで簡単な実験をしてみた。

int hoge()
    {
            int a = 10;
            asm("mov r3, #100; str r3, [%0]" : : "r"(&a) : "r3");
            return a;
    }

というコードを最適化オプションなしで、コンパイルしてみる。

<hoge>:
        push {fp}  ; (str fp, [sp, #-4]!)
        add fp, sp, #0
        sub sp, sp, #12
        mov r3, #10
        str r3, [fp, #-8]
        sub r2, fp, #8
        mov r3, #100 ; 0x64
        str r3, [r2]
        ldr r3, [fp, #-8]
        mov r0, r3
        add sp, fp, #0
        pop {fp}  ; (ldr fp, [sp], #4)
        bx lr

となった。

毎回、変数の値をメモリまで取りに行くので、これは `100` を返す。

一方、 `-O2` オプションをつけてコンパイルしてみると

<hoge>:
        sub sp, sp, #8
        add r2, sp, #4
        mov r3, #100 ; 0x64
        str r3, [r2]
        mov r0, #10
        add sp, sp, #8
        bx lr

となった。

これは `10` を返す。

インラインアセンブラの中で 変数 `a` が書き変わっているのに気づかないので、即値 `10` を返すように最適化するわけだ。

最適化オプションをつけるかつけないかで、関数の結果が変わるのはもちろん困る。

そこで、インラインアセンブラの中でメモリの中身が書き変わっていますよ、
とコンパイラに教えてあげるために、破壊リストに `"memory"` を追加する。

int hoge()
    {
            int a = 10;
            asm("mov r3, #100; str r3, [%0]" : : "r"(&a) : "r3", "memory");
            return a;
    }

をコンパイルすると

<hoge>:
        sub sp, sp, #8
        mov r3, #10
        add r2, sp, #8
        str r3, [r2, #-4]!
        mov r3, #100 ; 0x64
        str r3, [r2]
        ldr r0, [sp, #4]
        add sp, sp, #8
        bx lr

となった。

`return` の前にちゃんと変数 `a` をメモリから取り直してくれるので、 `100` が返る。

Linux Kernel にはメモリバリアを挿入するための `barrier()` という関数がある。

定義は `include/linux/compiler-gcc.h` にあって、

/* Optimization barrier */
    /* The "volatile" is due to gcc bugs */
    #define barrier() __asm__ __volatile__("": : :"memory")

となっている。

なんでこれがメモリバリアの役割の果たすのか、ここまで読んできたらほぼ明らかだろう。
`-O2` オプションをつけてコンパイルすると

void hoge(int *a, int *b)
    {
            *a = 10;
            *b = *a;
    }

は

<hoge>:
        mov r3, #10
        str r3, [r0]
        str r3, [r1]
        bx lr
となる。

最適化によって `*a` からのリードが欠落している。

一方、

void hoge(int *a, int *b)
    {
            *a = 10;
            __asm__ __volatile__("" : : : "memory");
            *b = *a;
    }

は

<hoge>:
        mov r2, #10
        str r2, [r0]
        ldr r3, [r0]
        str r3, [r1]
        bx lr

となって、コード通り、 `*a` から `*b` へコピーしている。

コンパイラはメモリバリアを越えた最適化を行わなくなるが、
ハードウェアによる実行時並べ替え（Out of Order 実行）が行われる可能性はあります。

実行時のメモリアクセスの最適化を許すかどうかは ARM の場合はページテーブルの属性で指定されます。

拡張インラインアセンブラの勉強 1

拡張インラインアセンブラ、けっこう難しくてなかなか覚えられません。。

[GCC Inline Assembler](http://caspar.hazymoon.jp/OpenBSD/annex/gcc_inline_asm.html)
というサイトを見ながら、もう一回勉強してみた。

基本的に

asm( アセンブリテンプレート : 出力オペランド : 入力オペランド : 破壊レジスタ);

というフォーマットでいいのですが、「出力オペランド」と「入力オペランド」はわかるとして、
「破壊レジスタ」というのがいまいちピンときません。

そこで、「破壊レジスタ」を指定するのとしないのとで、どのような違いが出るのか、
ARM gcc の逆アセを見ながら勉強してみた。

まずは、普通に(拡張でない)インラインアセンブラを書いた場合

int hoge()
    {
            register int a = 10, b = 20;
            asm("mov r4, #100");
            return a + b;
    }

をコンパイルすると

<hoge>:
        push {r4, r5, fp}
        add fp, sp, #8
        mov r5, #10
        mov r4, #20
        mov r4, #100 ; 0x64
        add r3, r5, r4
        mov r0, r3
        sub sp, fp, #8
        pop {r4, r5, fp}
        bx lr

となった。

コンパイラは前後関係を考慮することなく、単に `mov r4, #100` を挿入するだけなので、
`30` ではなく、 `110` を返すコードが生成された。
(変数 `b` が `r4` に取られているためだが、これは事前に予測不能である。)

そこで拡張インラインアセンブラを使って、 `r4` が破壊されることを指定する。

int hoge()
    {
            register int a = 10, b = 20;
            asm("mov r4, #100" : : : "r4");
            return a + b;
    }

は

<hoge>:
        push {r4, r5, r6, fp}
        add fp, sp, #12
        mov r6, #10
        mov r5, #20
        mov r4, #100 ; 0x64
        add r3, r6, r5
        mov r0, r3
        sub sp, fp, #12
        pop {r4, r5, r6, fp}
        bx lr

なるほど、 `r4` を避けて、 変数 `a`, `b` を `r6`, `r5` に割り当てています。
しかもちゃんと `r4` をスタックに退避してくれています。

ではコンパイラを困らせてやれと思って、

int hoge()
    {
            register int a = 10, b = 20;
            asm("mov r4, #100" : : : "r4", "r5", "r6", "r7", "r8", "r9", "r10");
            return a + b;
    }

とすると、

<hoge>:
        push {r4, r5, r6, r7, r8, r9, sl, fp}
        add fp, sp, #28
        sub sp, sp, #8
        mov r1, #10
        str r1, [fp, #-32] ; 0xffffffe0
        mov r2, #20
        str r2, [fp, #-36] ; 0xffffffdc
        mov r4, #100 ; 0x64
        ldr r1, [fp, #-32] ; 0xffffffe0
        ldr r2, [fp, #-36] ; 0xffffffdc
        add r3, r1, r2
        mov r0, r3
        sub sp, fp, #28
        pop {r4, r5, r6, r7, r8, r9, sl, fp}
        bx lr

となった。

レジスタ変数をとれなくなって、変数 `a`, `b` はスタックに確保している。

ただし、破壊レジスタに `r11` を指定すると

error: fp cannot be used in asm here

というエラーが出る。

一応、以下のようにほとんど破壊レジスタリストに指定しても、つじつまの合うように動くようです。

int hoge()
    {
            register int a = 10, b = 20;
            asm("mov r13, #0x81000000" : : :
                "r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
                "r8", "r9", "r10", "r12", "r13", "r14");
    
        return piyo(a, b);
    }

をコンパイルすると、

<hoge>:
        push {r4, r5, r6, r7, r8, r9, sl, fp, lr}
        add fp, sp, #32
        sub sp, sp, #12
        mov r3, #10
        str r3, [fp, #-40] ; 0xffffffd8
        mov r3, #20
        str r3, [fp, #-44] ; 0xffffffd4
        mov sp, #-2130706432 ; 0x81000000
        ldr r0, [fp, #-40] ; 0xffffffd8
        ldr r1, [fp, #-44] ; 0xffffffd4
        bl <piyo>
        mov r3, r0
        mov r0, r3
        sub sp, fp, #32
        pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}

register 変数

[前回](/2012/04/blog-post.html)に引き続いて、 レジスタ変数を使った時の逆アセがどうなるかを見てみた。
ARM でやっています。

int hoge()
    {
            register int a = 10, b = 20;
            return a + b;
    }

をコンパイルしてみると

<hoge>:
        push {r4, r5, fp}
        add fp, sp, #8
        mov r5, #10
        mov r4, #20
        add r3, r5, r4
        mov r0, r3
        sub sp, fp, #8
        pop {r4, r5, fp}
        bx lr

なるほど、変数 `a`, `b` を `r5`, `r4` に取るのね。
`r4` - `r11` は復元の必要があるので、いったんスタックに退避してます。

では、 register 変数は何個まで取るんだろうという素直に思ったので、やってみた。

int hoge()
    {
            register int a = 10, b = 20, c = 30, d = 40;
            register int e = 50, f = 60, g = 70, h = 80;
            return a + b + c + d + e + f + g + h;
    }

をコンパイルしてみると

<hoge>:
        push {r4, r5, r6, r7, r8, r9, sl, fp}
        add fp, sp, #28
        sub sp, sp, #8
        mov r2, #10
        str r2, [fp, #-32] ; 0xffffffe0
        mov r9, #20
        mov sl, #30
        mov r8, #40 ; 0x28
        mov r7, #50 ; 0x32
        mov r6, #60 ; 0x3c
        mov r5, #70 ; 0x46
        mov r4, #80 ; 0x50
        ldr r2, [fp, #-32] ; 0xffffffe0
        add r3, r2, r9
        add r3, r3, sl
        add r3, r3, r8
        add r3, r3, r7
        add r3, r3, r6
        add r3, r3, r5
        add r3, r3, r4
        mov r0, r3
        sub sp, fp, #28
        pop {r4, r5, r6, r7, r8, r9, sl, fp}
        bx lr

変数 `b` ～ `h` は `r4` ～ `r10` に割り当てられているが、変数 `a` はレジスタに取れずに、スタックに確保しているみたい。

ちなみに `sl` は `r10` のこと。

レジスタの別名をまとめてみた。

- `r9` = `sb`: スタティックベース
- `r10` = `sl`: スタックリミット
- `r11` = `fp`: フレームポインタ
- `r12` = `ip`: プロシージャコール内スクラッチ
- `r13` = `sp`: スタックポインタ
- `r14` = `lr`: リンクレジスタ
- `r15` = `pc`: プログラムカウンタ

2012年4月5日木曜日

関数のプロローグとエピローグ

関数のプロローグとエピローグにどういう意味があるのか調べてみました。

とりあえず、ARM の gcc コンパイラで実験してみた。

最適化オプション (`-O`) はつけてない。

void hoge()
    {
    }

をコンパイルすると

<hoge>:
        push {fp}  ; (str fp, [sp, #-4]!)
        add fp, sp, #0
        add sp, fp, #0
        pop {fp}  ; (ldr fp, [sp], #4)
        bx lr

となった。

`fp` は `r11` のこと。フレームポインタの意味らしい。

- 関数に入るとき（プロローグ）に `fp` をスタックに退避し、 `sp` の値を `fp` にコピー。
- 関数から出るとき（エピローグ）に `fp` を `sp` にコピーしたあと、 `fp` を復元。

となっているが、これだけ見ると、なんでこんな周りくどいことするのかよく理解できない。

そこで

int hoge()
    {
            int a = 10;
            return a;
    }

をコンパイルしてみた。

<hoge>:
        push {fp}  ; (str fp, [sp, #-4]!)
        add fp, sp, #0
        sub sp, sp, #12
        mov r3, #10
        str r3, [fp, #-8]
        ldr r3, [fp, #-8]
        mov r0, r3
        add sp, fp, #0
        pop {fp}  ; (ldr fp, [sp], #4)
        bx lr

となった。

これを見ると、 `sp` を `fp` へコピーした後、スタックを `12` 伸ばしている。
この時点で、 `sp = fp - 12` という関係がある。

例えば、関数に入った時点の `sp` の値が `0x80000000` だったとして、
スタックの使い方は

0x7ffffff0: 未使用   <-- sp の指す位置
    0x7ffffff4: 変数 a
    0x7ffffff8: 未使用
    0x7ffffffc: 復帰用fp <-- fp の指す位置

となっているはず。

さらに

int hoge()
    {
            int a = 10, b = 20;
            return a + b;
    }

をコンパイルしてみると

<hoge>:
        push {fp}  ; (str fp, [sp, #-4]!)
        add fp, sp, #0
        sub sp, sp, #12
        mov r3, #10
        str r3, [fp, #-8]
        mov r3, #20
        str r3, [fp, #-12]
        ldr r2, [fp, #-8]
        ldr r3, [fp, #-12]
        add r3, r2, r3
        mov r0, r3
        add sp, fp, #0
        pop {fp}  ; (ldr fp, [sp], #4)
        bx lr

となった。

スタックの使い方は

0x7ffffff0: 変数 b   <-- sp の指す位置
    0x7ffffff4: 変数 a
    0x7ffffff8: 未使用
    0x7ffffffc: 復帰用fp <-- fp の指す位置

さらにさらに

int hoge()
    {
            int a = 10, b = 20, c = 30;
            return a + b + c;
    }

は

<hoge>:
        push {fp}  ; (str fp, [sp, #-4]!)
        add fp, sp, #0
        sub sp, sp, #20
        mov r3, #10
        str r3, [fp, #-8]
        mov r3, #20
        str r3, [fp, #-12]
        mov r3, #30
        str r3, [fp, #-16]
        ldr r2, [fp, #-8]
        ldr r3, [fp, #-12]
        add r2, r2, r3
        ldr r3, [fp, #-16]
        add r3, r2, r3
        mov r0, r3
        add sp, fp, #0
        pop {fp}  ; (ldr fp, [sp], #4)
        bx lr

となった。

スタックは

0x7fffffe8: 未使用   <-- sp の指す位置
    0x7fffffec: 変数 c
    0x7ffffff0: 変数 b
    0x7ffffff4: 変数 a
    0x7ffffff8: 未使用
    0x7ffffffc: 復帰用fp <-- fp の指す位置

となっているはず。

以上を見ると、

- `fp` と `sp` の間に自動変数を確保しているらしい。
- `sp` の伸ばす量は 8 ずつ増えている。

という規則があることがわかった。

ただし、上記の例で、 `0x7ffffff8` の位置が常に未使用になっているのがちょっと不思議です。

そこで、以下の関数をコンパイルしてみて納得。

int hoge()
    {
            int a = 10, b = 20;
            return piyo(a, b);
    }

<hoge>:
        push {fp, lr}
        add fp, sp, #4
        sub sp, sp, #8
        mov r3, #10
        str r3, [fp, #-8]
        mov r3, #20
        str r3, [fp, #-12]
        ldr r0, [fp, #-8]
        ldr r1, [fp, #-12]
        bl <piyo>
        mov r3, r0
        mov r0, r3
        sub sp, fp, #4
        pop {fp, pc}

となった。

なるほど、この場合は `fp` と `lr` の両方を退避しておく必要があるのね。

0x7ffffff0: 変数 b   <-- sp の指す位置
    0x7ffffff4: 変数 a
    0x7ffffff8: 復帰用fp
    0x7ffffffc: lr       <-- fp の指す位置

ちなみに、 ABI によると、 `r0-r3`, `r12` は復元しなくてよいレジスタ、 `r4-r11` は復元しなくてはならないレジスタです。

2012年2月24日金曜日

C言語のswitch文で ...

Linux のコードを見ていると、こんな書き方もできるのかぁ、というものに出くわすことがありますね。

例えば、
arch/arm/mach-rpc/irq.c にある、以下のようなコード。

                switch (irq) {
                case 0 ... 7:
                        irq_set_chip_and_handler(irq, &iomd_a_chip,
                                                 handle_level_irq);
                        set_irq_flags(irq, flags);
                        break;
                case 8 ... 15:
                        irq_set_chip_and_handler(irq, &iomd_b_chip,
                                                 handle_level_irq);
                        set_irq_flags(irq, flags);
                        break;
                case 16 ... 21:
                        irq_set_chip_and_handler(irq, &iomd_dma_chip,
                                                 handle_level_irq);
                        set_irq_flags(irq, flags);
                        break;
                case 64 ... 71:
                        irq_set_chip(irq, &iomd_fiq_chip);
                        set_irq_flags(irq, IRQF_VALID);
                        break;
                }

「...」で範囲指定できるらしい。見た時びっくりしました。

gcc のマニュアルを参照すると
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/C-Extensions.html#C-Extensions

これはGNU 拡張機能らしいです。
(Case Ranges: `case 1 ... 9' and such. )

gcc に -pedantic をつけると非標準機能を使っていると警告してくれるみたい。
ポータビリティを気にする場合は便利かも。

上のような書き方をすると

警告: range expressions in switch statements are non-standard

という風に warning 出してくれました。

登録: 投稿 (Atom)