「 2014年11月 」一覧

MIPS Creator CI20 用Mingw版クロスコンパイラ

先日のものでは Hello,World 程度のコンソールアプリでは問題なかったものの、他のライブラリをリンクした際に正常に処理できなかったので、早速クロスコンパイラ関連を作り直しました。

今回の物も完全とはいえないのですが、まだ使えるようになったと思うのでここに公開したいと思います。

使い方・注意点

適当な場所に展開して下さい。デバッガーとしての gdb が少々怪しく、 eclipse からは mipsel-unknown-linux-gnu-gdb_for_eclipse を使用し、コンソールでがんばる方は mipsel-unknown-linux-gnu-gdb を使うようにしてみてください。なぜか後者の方は eclipse からうまく扱えなかったので・・・。またデバッグ時にはターゲットの lib らの情報が欲しいようなので、 sysroot ディレクトリを gdb の set sysroot で設定してあげるようにしてください。

なお、本ツールを用いての不具合等については当方で責任は負いかねますので、その点をご了承下さい。

ダウンロード

前回の公開記事のほうでリンクを張り直しました
新ファイルイメージ公開のため、クロスコンパイラの作り直しを行いました。こちらのほうをご参照ください「クロスコンパイラ (MIPSCreatorCI20 / Jetson TK1)

補足

今回のクロスコンパイラを用いて、簡単な OpenGL ES 2.0 のアプリケーションを Windows で作成して実行してみました。ターゲットに含まれていた各ライブラリをリンクして無事にアプリができたことを確認してみたつもりです。

ci20_gles20

なお CI20 では一見、普通の OpenGL が使えるようにライブラリが含まれているように見えましたが、実際のところは glCompileShader 関数で Segmentation Fault してしまいます。 OpenGL ES 2.0 で処理を記述すれば問題なく glCompileShader も正常終了しました。


ようやくクロスコンパイラ出来た

ここ最近ひたすらクロスコンパイラの準備に励んでいた理由の1つに、Imagination Technologies の Creator CI20 が手元に届いたから、というのがありました。そしてようやくですが Linaro の環境を真似して、 Creator CI20 用の環境を準備してみました。うまく動かない部分もあるかもしれませんが、ひとまずは下記に示すように Windows 環境での開発が出来そうなところまで到達出来たと思います。

ci20-on-eclipse

eclipseの基本的な設定は、Jetson TK1のときと同様の手順で行ってあります。1点違うのは今回は .gdbinit ファイルを作成したことです。この gdbinit ファイルの中では、 CI20 から取り出した include, lib らなどの場所、いわゆるsysrootの設定が記載してあります。

これらのビルド済みツールチェインを以下の場所で公開してみます。また使用しているCI20用のsysrootらについてもこのツールチェインの中に含めてみました。
eclipse らで使用する際には、このsysrootを指すように gdbinit を設定してください。

Download for MIPS Creator CI20 Toolchains(Pre-Built)


Download (ci20_mipsel-unknown-linug-gnu_mingw32.tar.xz)
上記の場所にファイルをおいてあります。


新ファイルイメージ公開が公開されたため、クロスコンパイラの作り直しを行いました。こちらのほうをご参照ください「クロスコンパイラ (MIPSCreatorCI20 / Jetson TK1)

不具合とかあっても対処できませんので、利用は自己責任でお願いします。

蛇足的メモ

結局 crosstool-ng の中でカナディアンクロスでコンパイラを作成しました。これでもクロスの gdb 作成過程で expat のライブラリが見つからないとかでエラーになる始末で、最終的にはあきらめました。結果、MinGW の環境で gdb だけはクロスターゲットのものを make して同梱する形にしました。強引な感じで心配ですが、とりあえず動いているようなので様子見です。

カナディアンクロスの際には単に build, host, target を指定するだけでは終わらず、ビルドホストからhost, target の両クロスコンパイラがまずは必要になるようです。そのため linux -> mips, linux -> mingw32 といったツールチェイン&コンパイラを作成してから作業しました。今回の場合では linux -> mingw32 のクロスコンパイラを基盤に使用していくことになったので、これもまた crosstool-ng にて生成させることにしました。

外部ツールに頼ってしまっていますが、ようやくやりたいことが実現したので満足です。より詳細な内容は今回の手順の中身を追っていけば把握できるでしょうし、そのうちこの中身を手作業で追いかけてみたいなとは思います。


ARMのプログラムを作成してデバッグする 第5回

前回でボタン1つでリモートデバッグが開始できるところまで到達して完結したのですが、友人からSftp使えない環境では使えないと指摘を頂きました。今回はそれに対処してみようと思います。

sftpが封じられている場合でも ssh,scp らは利用可能であることが多いです。そのためこれらを用いる方向で対処します。eclipse に Remote System Explorer をインストールしましたが、これのさらなるオプションで scp を使える物があります。「RSE SCP File Services(Incubation)」とプラグイン名はなってます。
 これを今まで作成してきた環境にセットアップすると、sftpの代わりに scp を使用して実行体を送ってくれるようにできます。注意事項としては Remote System Explorer 本体とのバージョン整合性を取ってあげることです。間違ったバージョンを入れるとこのSCPプラグインが見えないようです(自分の場合はそうだった・・)


cygwinでクロスgccのmakeは出来たが・・・

クロスコンパイラを自力でビルドしたいという、同じような病気に既にかかっている方がいらっしゃるようで、その情報が非常に参考になりました。こちらを参考にして自分もまたクロスコンパイラ gcc の make に勤しんでいます。

世の中のいろいろな情報により gcc の make は出来るようになっていますが、上記で掲載されている生成用のスクリプトがかなり勉強になります。スクリプトの動作は Ubuntu 14.04 にて確認してうまく動いたので、これを元に cygwin で作業してみることにしました。

先日の日記にあるように、 eglibc 2.13 や gcc については、 cygwin 環境ならではの問題点があるのでこれらについてパッチを当てる形で上記のスクリプトに改良を加えてみました。

この結果、 cygwin 環境でもうまく gcc が生成させることが出来、待望の「スレッドモデル: posix」と表示されるクロスコンパイラ gcc となりました!

今確認出来ているものの構成要素は以下の通りです。

  • gmp-4.3.2
  • mpfr-2.4.2
  • mpc-0.8.1
  • binutils-2.21.1
  • gcc-4.5.3
  • eglibc-2.13
  • linux-3.0.45
  • target: arm-none-linux-gnueabi

しかしながら・・・

これで一応 cygwin の中で クロスgcc がスレッドモデルが posix となるところまででき、また elf バイナリが出力できるところまでは確認できました。しかしながら、いざターゲットに持って行くと正常に実行できるバイナリになっておらず・・・。まだ完成とはならなかったようです。

クロスコンパイラ gcc の完成はターゲットでちゃんと実行できる物ができて、初めて完成といえるのでまだちょっとかかりそうです。欲を言えば、デバッグがちゃんとホストでできるように gdb も準備できるまでが、環境構築のフェーズですね。まだまだかかりそう・・・。


クロスコンパイラgcc作成に再びチャレンジ中

クロスコンパイラ gcc を作成したい!という病気に再びかかってしまいまして、リトライ中です。色々と試行錯誤の結果 Linux 環境下では何となくうまくいくようになってきまして、現在最終目標である Windows 環境下で動く gcc を作りたいと思って作業中です。
 このとき、まずはと思って cygwin を使用しているのですが、結構これが罠でした。 cygwin がというよりは Windows の標準の挙動がマズイ点もあるんですが次のような問題に出遭ってしまいました。

cygwinで eglibc, gcc をビルドするのに致命的だった点

.os, .oS という中間ファイルを生成していた点で windows が通常大文字小文字を区別していないため、同一ファイルとして扱ってしまうこと。これを回避するために、.oST として Makefile らを修正する必要がありました。
結構有名な話のようで、 glibc でも同様だとか。これらについてはパッチが出回っているのでそれを適用すれば OK な模様です。
なお、 eglibc の cygwin ビルドについては、他にもまだ修正箇所があるのでこれもまたパッチを適用して回避します。

cygwin 用のパッチが不十分で、まだエラーが出ることがあります。そのため、以下のようにソースコードに修正を加えて対処します (diff形式で出しておきます) 。自分の場合では、 rpc/types.h が見つからない!というエラーが出ました。

そのほかにも gcc 4.5.3 の make では問題が発生しました。自分の環境も影響しているかもしれませんが、 gcc のビルドステップ3番目の箇所で libstdc++ の作成箇所でコンパイル内部エラーが発生してしまいました。
これについては、どうやらプリコンパイル済みヘッダの挙動が影響しているらしく、 cygwin 環境時には使用しない方向で、 –disable-libstdcxx-pch オプションをつけることで対処してみました。

gcc の make ってやはり大変です。 cygwin という環境も手伝ってなおさらです。


ARMのプログラムを作成してデバッグする 第4回

前回まででコードのクロスコンパイルをeclipse上で行うところまで出来たので、今回はデバッグについて設定を行っていきたいと思います。ターゲット上で動いているプログラムに対するデバッグとなるので、リモートデバッグを設定するという感じになります。

gdbserverを手動で起動する系

まずはターゲットでgdbserverを手動で動かして、そこに eclipse が接続を行う、というタイプで設定してきます。どこに問題があるか切り分けるためにも、まずはここから設定します。ワンタッチでリモートデバッグという点については後半で説明します。

コンパイル後出来上がったターゲット用のelfファイルをターゲット(実機)へ転送します。デフォルトだとDebugフォルダ以下に出来ていると思います。 Remote System Explorer パースペクティブを開いて、そのファイルを sftp 経由でターゲットの適当な場所へコピーします。
ここでは、 Jetson TK1 ターゲット標準ユーザーである ubuntu ユーザーのホームにプログラムを送ることにしました。
エクスプローラーからファイルを Remote Systems タブ内へのドラッグアンドドロップで任意の場所に転送できます。( eclipse 内でファイルのD&Dする方法はちょっと見当たらず・・・)

ターゲットでの操作

プログラムを転送したら、ターゲットでgdbserverでそのプログラムを実行します。
eclipse の Remote Systems から ssh Terminal を起動して操作するか、ターゲットのキーボードをたたいてコマンドを実行して下さい。
初回の転送後はファイルが実行属性が付いていないので、それも設定する必要があります。

実際に待っているとこうなります。
waiting_gdb

eclipseのデバッグ設定

この待ち受けしているターゲットに対して、gdb接続をするための設定を行っていきます。
プロジェクトを右クリックして、 Debug As / Debug Configuration を選んで、設定画面を出して下さい。

そして、「C/C++ Application」を選んで、 New Launch Configuration ボタンを押してコンフィグを作成します。作成すると以下のような感じになると思います。

debug_configuration_1

そして、画面下部のほうにある 「Using GDB(DSF) Create Process Launcher – Select Other 」 のリンク部分をクリックして、次のように設定します (Standard Create Process Launcher を選択)。

standard_create_process_launcher

次に、Debuggerタブを開きます。そして以下の設定に変更します。(Standard Create Process Launcher を選択しないと以下の設定ができないんです)。

  • Debugger: gdbserver
  • GDB Debuger: D:\Linaro\gcc-linaro-arm-linux-gnueabihf-4.8-2014.04\bin\arm-linux-gnueabihf-gdb.exe

debugger_tab_gdbserver

上記を見てわかるとおり arm-linux-gnueabihf-gdb.exe のフルパスが入っています。ここは各自の環境に合わせて修正してください。

この中の「connection」タブを開き、以下のように設定して下さい。

  • Type: TCP
  • IP Address: ターゲットのIPアドレス
  • Port Number: 2345

これらの設定が終わったら、Apply ボタンを押して、Debug ボタンを押してデバッグを開始します!!
うまく設定ができていれば以下のようにブレークポイントを設定したところで停止します。
eclipse_debugbreak

全てを自動で!ボタン1つでリモートデバッグを開始

今までのものがうまくできていれば、もう後一歩で手軽なリモートデバッグができるようになります。ここで実現することは、ビルドしたファイルを転送し、 eclipse のデバッガ操作を受け付けるようにする、といったものです。すなわち前章で手作業をした部分ですね。

ターゲットの設定

今回は特に必要ありません。gdbserverがパスの通った場所に配置されていればOKです。

eclipseの設定

先ほどと同じですが、デバッガ設定の部分が異なります。ですので、Debug Configurationの画面を開きます。

今度は「C/C++ Remote Application」を選んで、 New Launch Configuration ボタンを押してコンフィグを作成します。作成すると以下のような感じになると思います。

debug_configuration_remote_1

ここで先ほどと同様に、画面下部のほうにある 「Using GDB (DSF) Automatic Remote Debugging Launcher – Select Other 」 のリンク部分をクリックして、次のように設定します ( Standard Remote Create Process Launcher を選択)。
debug_configuration_remote_2

すると戻ったときに画面が変わりますので、以下のように編集します。基本的には、以前に作成した接続情報を選択したり、実行体バイナリを配置するパスを記入したりといったことになります。

debug_configuration_remote_3

みてわかるとおり、実行前の処理で実行属性をつけています。続いて、Debugger タブを開いてさらに設定をおこないます。
基本的には、さきほどやったように使用する gdb のフルパスを入れたり、プロトコルを設定したりします。

debug_configuration_remote_4

ここでプロトコルを「mi2」に指定してます。これがポイントで、 default, mi1 とか設定の場合、自分の環境ではうまくデバッグ接続を確立できませんでした。

設定が終わったら、 Apply ボタンを押して、 Debug ボタンを押して、リモートデバッグを開始します。うまくいけば以下のようにブレークポイントで停止した状態になると思います。

debug_configuration_remote_result

まとめ

ようやくボタン1つでリモートデバッグができるところまでたどり着けました。しかも基本 Windows 環境なので、通常Windowsを使っているユーザーには開発の敷居が低くなった、と自負しております。 VMPlayer に Ubuntu などの Linux 環境を入れてそこで開発するスタイルに比べれば、動作が比較的軽いと思いますし、その点でも環境はよくなったと思います。
今回、makeの都合で若干MinGWのお世話になってしまいますが、それでも cygwin よりはまだWindowsよりといっていいと思います。cygwin でコンソールでがんばって開発するスタイルもまたアリだと思いますけど、やっぱりデバッギングは GUI が色々とあった方が効率よいですしね!

今回は Jetson TK1 で行いましたが、他のターゲット(Raspberry PIや類似基板、他のボードなど)でも、そこそこ同じ手順で環境実現出来るんじゃないかと予想しています。またそれらのものを触る機会があったらご報告したいと思います。やってみた方のコメントもまた募集しておきたいと思います。