2010年01月
2010年01月26日
QEMUはAndroidのSDKのエミュレータにも使われています。
QEMUのARMのシステムエミュレータをソースからビルドして、その上でDebianを動かしてみたので、その方法を紹介します。
（最近0.12.2がリリースされましたが、私の環境ではうまくうごかなかったので、0.12.1でのビルド手順を紹介します。)
2010年01月22日
GCC のソースツリー中の gcc/config/arm/ 以下には、OCaml という関数型（プログラミングを支援する）言語 ML (Meta-Language) の方言で書かれたプログラムが存在しています。
NEON 命令のためのヘッダ、テストケース、ドキュメントなどを生成するために O'Caml プログラムが使われているようです。
Contents of /trunk/gcc/config/arm/neon-gen.ml
Contents of /trunk/gcc/config/arm/neon-schedgen.ml/a>
Contents of /trunk/gcc/config/arm/neon-testgen.ml
Contents of /trunk/gcc/config/arm/neon.ml
Contents of /trunk/gcc/config/arm/neon-docgen.ml
OCaml は言語処理系の開発によく使用される言語なのですが、まさか GCC の内部でも使われている（直接は関わっていないのですが。生成済みのヘッダが trunk に commit されているので、GCC のビルドの際には O'Caml 処理系は必要ありません。）とは思ってなかったので意外でした。(佐藤先輩に教えていただきました。)
参考リンク:
Modern Compiler Implementation in ML
有名なタイガーブックです。ML の他にも、Java と C による同内容の本が出ていて、Java が一番いろいろなところで参考文献として挙げられている気がします。
Fail-Safe C: 安全なC言語コンパイラ
O'Caml で書かれた C コンパイラです。
CIL (C Intermediate Language)
C のソースコードを解析して、解析が容易な形 (中間言語) に変換する O'Caml のライブラリです。ANSI C だけではなく、GNU 拡張や MS 拡張 (の一部) までサポートしているそうです。ソースコード解析系の研究で、比較的よく使われているような印象です。
NEON 命令のためのヘッダ、テストケース、ドキュメントなどを生成するために O'Caml プログラムが使われているようです。
Contents of /trunk/gcc/config/arm/neon-gen.ml
Contents of /trunk/gcc/config/arm/neon-schedgen.ml/a>
Contents of /trunk/gcc/config/arm/neon-testgen.ml
Contents of /trunk/gcc/config/arm/neon.ml
Contents of /trunk/gcc/config/arm/neon-docgen.ml
OCaml は言語処理系の開発によく使用される言語なのですが、まさか GCC の内部でも使われている（直接は関わっていないのですが。生成済みのヘッダが trunk に commit されているので、GCC のビルドの際には O'Caml 処理系は必要ありません。）とは思ってなかったので意外でした。(佐藤先輩に教えていただきました。)
参考リンク:
Modern Compiler Implementation in ML
有名なタイガーブックです。ML の他にも、Java と C による同内容の本が出ていて、Java が一番いろいろなところで参考文献として挙げられている気がします。
Fail-Safe C: 安全なC言語コンパイラ
O'Caml で書かれた C コンパイラです。
CIL (C Intermediate Language)
C のソースコードを解析して、解析が容易な形 (中間言語) に変換する O'Caml のライブラリです。ANSI C だけではなく、GNU 拡張や MS 拡張 (の一部) までサポートしているそうです。ソースコード解析系の研究で、比較的よく使われているような印象です。
2010年01月20日
前回の記事で少し触れた、Linux で使われているソースコード解析ツールである sparse は、Linux Kernel 以外のソースコードに対しても有益そうです。
Sparse - a Semantic Parser for C
MinGW 環境で試してみたところ、ちゃんと GNU C のソースコードを解析することができました。
続きを読む
Sparse - a Semantic Parser for C
MinGW 環境で試してみたところ、ちゃんと GNU C のソースコードを解析することができました。
続きを読む
2010年01月12日
Linux のソースコードでは、ユーザ空間とカーネル空間のポインタを区別するために、__user や __iomem などのマクロを変数に付けています。これは最終的には noderef や address_space(n) などの attribute に落ちて、sparse チェッカーというプログラムによってチェックされます。
参考: sparseチェッカー
これと同じように、異なるアドレス空間を指すポインタ変数に、アドレス空間ごとに任意の名前を付け、静的チェックや自動的に適切なコードを生成してくれるようなしくみがコンパイラにあれば、メモリが複数領域に分かれているような環境でのプログラミング時に便利です。これが名前付きアドレス空間サポートです。
時系列は追いきれてないのですが、2008 年 4 月に RFC が GCC の ML に提案されたようです。
RFC: named address space support
named-addr-spaces-branch という branch が存在し、更新はメインラインにマージされるそうです。
今のところは CELL/spu ターゲット限定のようです。
3.17.37 SPU Options
この方の記事が詳しいです。PIC や AVR などのプロセッサでは、ROM/RAM/FLASH というようにメモリ領域が分かれているため、名前付きアドレス空間のサポートが必要になってくるそうです。
ARMにはまった: GCCの名前つきアドレス空間サポート
ARMにはまった: まだまだねばるPIC用GCC、別アドレス空間の話
参考: sparseチェッカー
これと同じように、異なるアドレス空間を指すポインタ変数に、アドレス空間ごとに任意の名前を付け、静的チェックや自動的に適切なコードを生成してくれるようなしくみがコンパイラにあれば、メモリが複数領域に分かれているような環境でのプログラミング時に便利です。これが名前付きアドレス空間サポートです。
時系列は追いきれてないのですが、2008 年 4 月に RFC が GCC の ML に提案されたようです。
RFC: named address space support
named-addr-spaces-branch という branch が存在し、更新はメインラインにマージされるそうです。
今のところは CELL/spu ターゲット限定のようです。
3.17.37 SPU Options
この方の記事が詳しいです。PIC や AVR などのプロセッサでは、ROM/RAM/FLASH というようにメモリ領域が分かれているため、名前付きアドレス空間のサポートが必要になってくるそうです。
ARMにはまった: GCCの名前つきアドレス空間サポート
ARMにはまった: まだまだねばるPIC用GCC、別アドレス空間の話
2010年01月08日
GCC 4.5 から、libstdc++ のみをスタティックリンクするための -static-libstdc++ オプションが追加されたそうです。
「PATCH RFA: Add -static-libstdc++ option to g++」
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01635.html
g++ は、過去のバージョンアップで何度か ABI が変わっています（2.95、3.1、3.3、4.0 で互換性が失われているそうです)し、これからも変わる可能性があります。
そのため、場合によっては適切な libstdc++ がダイナミックリンクできなくて、プログラムが動かなくなる可能性があります。
例えば上記の patch の説明では、gcc 自身を g++ でブートストラップする場合などが挙げられています。ビルドプロセスの途中で ABI が異なる g++ が複数動くことになると、ダイナミックリンクでは当然上手く動きません。
注意点として、libstdc++ をダイナミックリンクする C++ コードを dlopen() などを経由して使うことができなくなるようです。
「Re: -static-libgcc, static libstdc++.a and dynamicly loaded so files」
http://gcc.gnu.org/ml/gcc-help/2009-12/msg00186.html
「PATCH RFA: Add -static-libstdc++ option to g++」
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01635.html
g++ は、過去のバージョンアップで何度か ABI が変わっています（2.95、3.1、3.3、4.0 で互換性が失われているそうです)し、これからも変わる可能性があります。
そのため、場合によっては適切な libstdc++ がダイナミックリンクできなくて、プログラムが動かなくなる可能性があります。
例えば上記の patch の説明では、gcc 自身を g++ でブートストラップする場合などが挙げられています。ビルドプロセスの途中で ABI が異なる g++ が複数動くことになると、ダイナミックリンクでは当然上手く動きません。
注意点として、libstdc++ をダイナミックリンクする C++ コードを dlopen() などを経由して使うことができなくなるようです。
「Re: -static-libgcc, static libstdc++.a and dynamicly loaded so files」
http://gcc.gnu.org/ml/gcc-help/2009-12/msg00186.html
