KMC 京都マイクロコンピュータ株式会社

glibc のテストスイートを確認していた所、string/test-string.h にて以下のようなシンボルが使われていたのですが、このシンボルの出所が全くわからなくてしばらく悩んだので、その正体をメモしておきます。

extern impl_t __start_impls[], __stop_impls[];

続きを読む

QEMU の Windows 版は、標準（エラー）出力が exe のあるフォルダ内の stdout.txt/stderr.txt というファイルに出力されてしまうので、コマンドラインから使う際には不便だと長年思っていましたが、これは SDL ライブラリのバージョン 1.2 の仕様だったようです。最近の QEMU はバージョン 2.0 に対応しているので、コンソールに出力されます。MSYS2 上でビルドする際などに、SDL 1.2 と 2.0 が両方インストールされていると 1.2 が優先されてしまう場合があるので、configure 時に --with-sdlabi=2.0 を指定しておくと確実です。

Windows 10 Fall Creators Update から WSL (Windows Subsystem for Linux) が使用できるようになり、Windows で Ubuntu 等の Linux バイナリが実行できるようになり、非常に便利です。
諸事情により、MSYS2 上から WSL 内の実行ファイルを実行したい場合に、MSYS2 はコマンドライン文字列中のファイルパスを勝手に変換してしまうため、正しく wsl コマンド経由で WSL 内部のファイルにアクセスすることができなくて悩んだので、その解決策のメモです。
続きを読む

手元にあった弊社製の古い評価ボード KZM-ARM11-01（※1） で、musl libc のテストスイートを、開発中のバージョンの exeGCC（※2） でコンパイルして動かしてみた所、最適化オプション Os だと一部テストが FAIL するが、O2 だと PASS するという現象が発生しました。それだけだとよく聞くような話ですが、分割コンパイルしていて、別ファイルのコードを変更すると、アセンブラソースもオブジェクトファイルも全く同じなのにリンクすると期待通り動かなくなるなど、奇妙な挙動にだいぶ悩まされました。

続きを読む

お久しぶりです。だいぶ間が空いてしまいました。その間、全身性エリテマトーデス（SLE）という、免疫が狂って自分自身を攻撃してしまう原因不明の難病を発病し、半年ほど休職していたりと色々ありましたが、なんとか職場復帰することができました。またよろしくお願いします。

そんなこんなで浦島太郎状態なのですが、QEMU のサイトを久しぶりに見てみた所、Docker という仮想化技術を使用して QEMU の Windows 用バイナリをビルドできるようになったそうなので、試してみました。
続きを読む

MSYS2 を試してみた所、LLVM/Clang が比較的簡単にビルドできましたので紹介します。以前紹介した、VisualStudio でビルドする場合と比較すると、

1. LLVM/Clang のビルドに必要な、GCC、CMake、Python、GNU Make などの各種 GNU ツールが、Linux の APT や Yum のようなパッケージマネージャ（MSYS2 は Arch Linux の pacman を採用）でインストールできるので、環境構築や管理が楽。
2. VisualStudio は比較的大きく、有償（無料の Express エディションもありますが、常用には登録が必要）のソフトウェアなので、比較的コンパクトで自由なソフトウェアである MSYS2 の方が色々楽。
3. GNU 環境のコマンドライン操作に慣れている人には、MSYS2 の方が楽。

などの利点が考えられます。
続きを読む

Xilinx さんが公開している QEMUは Linux ホストのみサポートなのですが、一応ごにょごにょしてみたら Windows でも MinGW-w64 環境で動作させることができたので、メモを残しておきます。（ちゃんとした修正では無いことを、ご了承ください。）

続きを読む

GNU ld が ARM ターゲットのプログラムのリンク時に以下のような警告を出すケースに遭遇しました。（XXX.out は ELF ファイル名）

C:/PATH/TO/ld.exe: XXX.out: warning: sh_link not set for section `.ARM.exidx'

普通は出ない珍しい警告で、日本語ではほとんど情報が無くて調査に苦労したので、メモしておきます。
続きを読む

Design Solution Forum 2015 で、LLVM と GCC の違いや、弊社の（現在開発中の）ARM64 用 PARTNER デバッガのアセンブラ/逆アセンブラ表示に LLVM を使用した事例などを紹介（35 分）してきました。
続きを読む

過去に何回か似たような記事を書いてますが、それのアップデートです。

内容的には、以下とほとんど同じ内容です。このツールの組み合わせでビルドが成功したというメモです。

LLVM 3.5(git リポジトリ)をMS VC++でビルド (2014/3/6)

（2015/9/4 追記: 下記手順で Express 2015 for Windows Desktop と LLVM 3.7.0 でもビルドと動作を確認しました。リンク先、中央の Community 2015 ではなく、下の方の Express for Windows Desktop からダウンロードしてください。）

続きを読む

不具合原因の詳細や、根本的な対策まではわかっていませんが、とりあえず現象と回避策を整理がてら記しておきます。

- 現象

Ubuntu 14.04/15.04 64bit （x86_64）上で Windows で動作する sh-*-elf ターゲットのクロス gcc を、Ubuntu の MinGW ツールチェーンでカナディアンクロスビルドすると、その gcc で特定パターンをコンパイルした時に、コンパイラ内部エラー（ICE）が発生する不具合がある。

gcc 4.8.4/4.8.5/4.9.2/4.9.3 で確認。32bit (x86) exe でも 64bit (x64) exe でも同じ結果。4.9.x が特に起こりやすく、libgcc の fp-bit.c コンパイル時に ICE が発生する。（後述するが、再現コードも作成できた。）4.8.x でも locale-inst.cc に -O2 以上の最適化で発生する。これらは Linux 上でネイティブ動作する sh のクロス gcc では発生しない。ソースや依存ライブラリ、configure 時のオプション等は、host の設定以外は全て Windows 向けと同じ。（また、Ubuntu 14.04 と 15.04 ではネイティブ、MinGW 共に gcc のバージョンが異なるが、あまり関係無いようだ。）

- 現状の回避策

32bit の Ubuntu （i386）上でカナディアンクロスビルドする。

- 原因の予想

おそらく gcc のカナディアンクロスビルドシステムにバグがある。特に、64bit Linux のネイティブ gcc は long が 64bit なのだが、MinGW gcc は 32bit でも 64bit でも long が 32bit （LLP64 モデル）なので、（gcc が LP64 モデルの Linux 上で使われてきた歴史を考えても）そのようなマイナーなパターンの対策は不十分な可能性が高い。また、sh のバックエンドの sh.md ファイルの記述のしかたにも問題があると思われる。具体的には、Tbit 操作のために 0x80000000 という定数が必要なようなのだが、md ファイル内では 10 進符号付整数しか記述できないようで、(const_int -2147483648) という、32bit の INT_MAX（2147483647）を超える即値が記述されている ※1。さらにややこしいことに、md ファイルは、genrecog という gcc の内部ツールにより、insn-recog.c に変換されてビルドされるのだが、この genrecog はビルド途中でネイティブ gcc でビルドされて作られ、一方 insn-recog.c は MinGW gcc でビルドされるのだが、その際の long の長さの違いが考慮されていない可能性が高い。

※1 C コンパイラは、通常はトークン単位で処理を行うため、仮に - が付いていても、- と 2147483648 は独立して処理されるので、問題が起こることがある。そのため INT_MIN は、通常は (-INT_MAX-1) のように定義されることが多く、MinGW gcc の limits.h もそうなっている。

詳細は以下になります。
続きを読む

タイトルでほぼ終わりなのですが、binutils 2.22 以降では、以下のようにアセンブラのみで書かれた関数には %function 属性を付けないと、正しく ARM コードと thumb コードで interworking できないのでちゃんと付けましょう、というだけの話です…が、原因がわかるまでけっこう悩んだので経緯をメモしておきます。

    。。。。
    .global     foo
    .type        foo, %function
foo:
    。。。。

続きを読む

Ubuntu などの最近の Linux ディストリビューションは、MinGW 環境をターゲットにしたクロスコンパイラが標準パッケージに含まれているので、非常に簡単に Windows 向けのバイナリをコンパイルすることが可能です。Windows 上で MinGW + MSYS あるいは cygwin で、Linux を前提としたツールをコンパイルするのはそれなりに大変なので、Linux 環境でクロスコンパイルしている方も多いと思います。私も愛用しています。

わかってしまえば非常にマヌケな話なのですが、ビルドしたバイナリを Linux 上でテストまでしたいなと思い、何気なく wine（Windows API 互換レイヤー）をインストールして色々検証していて、久しぶりにビルドしてみたら、突然全く触ってないあたりのクロスコンパイル（正確には configure）が失敗するようになり、原因の究明に苦労したので、その時のメモです。
続きを読む

GNU make には、暗黙のルールの連鎖で中間ファイルを生成したら、自動的に削除するという仕様があるのですが、これと WIndows のファイルシステムの、ファイル名の大文字小文字を区別しないという仕様が組み合わさると、ファイルが削除されてしまうという現象があり、実際ハマったのでメモしておきます。

10.4 Chains of Implicit Rules
（make 3.79.1: 新堂安孝氏による日本語訳）：10.4 暗黙のルールの連鎖
続きを読む

前回の記事では、GDB のシミュレータを使用してクロス GCC の dejagnu testsuite を通す方法を紹介しました。

Linux上でビルドしたGCCクロスコンパイラを（簡易）テストする方法

しかし、ARM ターゲット（arm-none-eabi）だと、この方法では上手く行きませんでした。どうもいろいろ調べてみると、GDB のシミュレータは ARM11 ぐらいまでしか対応してないようで（この時のターゲット CPU は Cortex-A9）、それ以上新しい ARM の場合は QEMU ユーザーモード（Linux アプリ実行環境）を使用してテストを実行するようです。これもほとんどウェブ上に情報が無く、非常に苦労したので、その時のメモを公開します。

（弊社の exeGCC の前任者の方が残してくださった技術メモやスクリプトには非常に助けられました。この場を借りてお礼申し上げます。）
続きを読む