Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsの覚え書き(コレジャナイ感?)
以前の幾つかのエントリで、Pleiades 4.3.2 Keplerでeclipse.orgのRemote Development Tools(RDT)プラグ
インによるリモートC/C++プロジェクトでの(リモート)ビルドや(リモート)デバッグを試してみたのですが、
良い感じで使えるところまで辿り着いていません。当初期待した点や期待と合っていた点や期待と違っていた
点は、以下の通りです。今のところ、これはちょっと違ったかな? という感じです。
当初期待した点
* 自己流のちょっと変なやり方ではない正統的なやり方のような気がした
* リモート環境側でsambaサーバを動かさなくてもSSHサーバを動かすだけで使えそうだった
試してみて期待と合っていた点
* リモートビルドが自然な感じで出来る
* sambaサーバを動かさなくてもSSHサーバを動かすだけでリモート側のソースを編集/ビルド出来る
試してみて期待と違っていた点
* デバッグが出来ない
* 編集ウィンドウの文法チェックが効かない
* リモート環境側にJava実行環境が必要(無くても最低限動くことは動きますが)
* コンパイラのデフォルトのインクルードフォルダが自動認識されない
* 自動ビルドが効かない
なお、これまで試してきたエントリは以下の通りです。
Win/Linuxクロス開発 | Pleiades KeplerにRemote Development Toolsをインストール
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートビルド (1)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートビルド (2)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートビルド (3)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートデバッグ失敗 (1)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートデバッグ失敗 (2)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートデバッグ失敗 (3)
ちなみに、PuTTYというオープンソースソフトウェアをPleiadesと組み合わせて使うことでもリモート環境の
ソースを編集/ビルドすることが出来ます。
Win/Linuxクロス開発 | WindowsからVMware Player上のUbuntuのコマンドを実行 (SSH編)
Win/Linuxクロス開発 | Pleiades Kepler + PuTTYのplink.exeでリモートビルド (1)
Win/Linuxクロス開発 | Pleiades Kepler + PuTTYのplink.exeでリモートビルド (2)
追記 : メモ
EclipseのヘルプのIBM社の日本語訳
(IBM社のEclipseベースの製品の為に公開されているものです。) (Eclipseのバージョンは?)
Win/Linuxクロス開発 | EclipseのRemote Development Toolsプラグイン日本語HelpのURL
Win/Linuxクロス開発 | EclipseのRemote System Explorerプラグイン日本語HelpのURL
インによるリモートC/C++プロジェクトでの(リモート)ビルドや(リモート)デバッグを試してみたのですが、
良い感じで使えるところまで辿り着いていません。当初期待した点や期待と合っていた点や期待と違っていた
点は、以下の通りです。今のところ、これはちょっと違ったかな? という感じです。
当初期待した点
* 自己流のちょっと変なやり方ではない正統的なやり方のような気がした
* リモート環境側でsambaサーバを動かさなくてもSSHサーバを動かすだけで使えそうだった
試してみて期待と合っていた点
* リモートビルドが自然な感じで出来る
* sambaサーバを動かさなくてもSSHサーバを動かすだけでリモート側のソースを編集/ビルド出来る
試してみて期待と違っていた点
* デバッグが出来ない
* 編集ウィンドウの文法チェックが効かない
* リモート環境側にJava実行環境が必要(無くても最低限動くことは動きますが)
* コンパイラのデフォルトのインクルードフォルダが自動認識されない
* 自動ビルドが効かない
なお、これまで試してきたエントリは以下の通りです。
Win/Linuxクロス開発 | Pleiades KeplerにRemote Development Toolsをインストール
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートビルド (1)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートビルド (2)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートビルド (3)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートデバッグ失敗 (1)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートデバッグ失敗 (2)
Win/Linuxクロス開発 | Pleiades Kepler + Remote Development Toolsでリモートデバッグ失敗 (3)
ちなみに、PuTTYというオープンソースソフトウェアをPleiadesと組み合わせて使うことでもリモート環境の
ソースを編集/ビルドすることが出来ます。
Win/Linuxクロス開発 | WindowsからVMware Player上のUbuntuのコマンドを実行 (SSH編)
Win/Linuxクロス開発 | Pleiades Kepler + PuTTYのplink.exeでリモートビルド (1)
Win/Linuxクロス開発 | Pleiades Kepler + PuTTYのplink.exeでリモートビルド (2)
追記 : メモ
EclipseのヘルプのIBM社の日本語訳
(IBM社のEclipseベースの製品の為に公開されているものです。) (Eclipseのバージョンは?)
Win/Linuxクロス開発 | EclipseのRemote Development Toolsプラグイン日本語HelpのURL
Win/Linuxクロス開発 | EclipseのRemote System Explorerプラグイン日本語HelpのURL
スポンサーサイト
2014/06/25 blog-entry-462 category: Pleiades & CrossGCC
Win/Linuxクロス開発 | CEV Linux SDKのx86 Linux Host版ARM Linux Cross GDBの盲点?
ルネサスRZ/A1Lマイコン搭載のコンピューテックス社製評価ボードCEV-RZ/A1LのCEV Linux SDKでは、x86
Linux Host版ARM Linux Cross開発環境しか提供されていません。とはいえ、やはり慣れている(というか好み
の)Windowsアプリケーションで作業したいところなので、前準備としてWindowsのPleiades 4.3 Keplerから
VMware Player上のx86 Linux GCC/GDBを実行出来ないか試した後、VMware Player上のARM Linux Cross
GCC/GDBを実行出来ないか試してみるつもりでした。ところが、CEV Linux SDK V2.00.00では、ARM Linux
Cross GCCはあるもののARM Linux Cross GDBがありませんでした。(これには、ちょっとメゲました、、、)
今まで試してきたこと (何がどこにあるか何がどこで動いているか)
これから試そうと考えていたこと (何がどこにあるか何がどこで動いているか)
しかしなぜか、CEV Linux SDK V2.00.00ではx86 Linux Host版ARM Linux Cross GDBがありませんでした。
(手違い? ちょっと使い道が想像出来ないx86 Linux Host版ARM Linux Cross GDBSERVERはあるのですが。)
その一方で、CEV-RZ/A1L上で動作するARM Linux GDBはありました。(また、GDBSERVERもありました。)
検索してみると、x86 Linux Host版ARM Linux Cross GDBも他と一緒にビルドされているようでしたが、、、
追記 : メモ
WindowsのPleiades(というかEclipse)が、シンボルの相互参照情報等を作成しようとしてソースコードツリー
全体をスキャンする時に、samba経由でVMware Player上のx86 Ubuntu Linuxのヘッダファイルにアクセス
することが原因で時間が掛かるようになった場合は、Linux側のGCC/Linuxヘッダファイルを丸ごとWindows
側にコピーしてしまうことも考えていました。
他方、Linux側からVMware Playerのフォルダ共有機能でアクセスするWindows側のフォルダ上にLinux側で
シンボリックリンクを作成出来ない制限があり、それが原因でmakeがコケてしまう場合は、Windows側に
ソースファイル/実行ファイルを置くことを諦め、Linux側にソースファイル/実行ファイルを置くようにして、
WindowsのPleiades(というかEclipse)からsamba経由でアクセスすることも考えていました。
さらに、makeがコケてしまう上にシンボルの相互参照情報等を作成しようとしてソースコードツリー全体を
スキャンする時に時間が掛かるようになった場合は、以前のエントリで試してみたEclipseでローカル環境と
リモート環境を同期可能なプラグインを使って、Windows側とLinux側の両方にソースファイルを置いてみる
つもりでした。
追記 : 雑感
上の追記に書いた2番目と3番目では、VMware Playerのフォルダ共有機能を使っていません。また、以前の
エントリ(438と460)では、VMware Playerのハードウェア仮想化されたCOMポートを使わなかったことも
あります。両者を組み合わせると、VMware Player固有の機能を使わずにLinux一般の機能だけを使うことに
なりますので、自己流のちょっと変なやり方のリモートビルドとリモートデバッグですが、Raspberry Piや
BeagleBone Blackでも出来そうな気がします。
追記 : 雑感
さらに、Linux MAKE(GNU MAKE)はパラレルビルドが可能ですので、大昔のエントリで以下のように書いた
ことも、サーバーが手配出来れば上の雑感に書いた組み合わせで、ちょっと試せそうな気もします。
'サーバーにファイルを保存したら、サーバー上で勝手にどんどんビルドしてくれる、そんなことが出来ると、
ちょっと面白そうな気がします。それに加え、CPUが何十個も搭載されたサーバーでは、パラレルで一気に
ビルドしてくれるとか、そんなことも出来たら、さらにもうちょっと面白そうな気がします、、、'
Linux Host版ARM Linux Cross開発環境しか提供されていません。とはいえ、やはり慣れている(というか好み
の)Windowsアプリケーションで作業したいところなので、前準備としてWindowsのPleiades 4.3 Keplerから
VMware Player上のx86 Linux GCC/GDBを実行出来ないか試した後、VMware Player上のARM Linux Cross
GCC/GDBを実行出来ないか試してみるつもりでした。ところが、CEV Linux SDK V2.00.00では、ARM Linux
Cross GCCはあるもののARM Linux Cross GDBがありませんでした。(これには、ちょっとメゲました、、、)
今まで試してきたこと (何がどこにあるか何がどこで動いているか)
| GCC/Linuxヘッダファイル | Linux側 (Windows側からsamba経由でリード) |
| GCC/Linuxライブラリ | Linux側 (Windows側からのアクセスは無いと思います) |
| ソースファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリード) |
| 実行ファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリードライト) |
| Pleiades 4.3 Kepler | Windowsで実行 |
| x86 Linux MAKE | VMware Player上のx86 Ubuntu Linuxで実行 |
| x86 Linux GCC | VMware Player上のx86 Ubuntu Linuxで実行 |
| x86 Linux GDB | VMware Player上のx86 Ubuntu Linuxで実行 |
| x86 Linux GDBSERVER | VMware Player上のx86 Ubuntu Linuxで実行 |
| 実行ファイル | VMware Player上のx86 Ubuntu LinuxのGDBSERVERで実行 |
これから試そうと考えていたこと (何がどこにあるか何がどこで動いているか)
| GCC/Linuxヘッダファイル | Linux側 (Windows側からsamba経由でリード) |
| GCC/Linuxライブラリ | Linux側 (Windows側からのアクセスは無いと思います) |
| ソースファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリード) |
| 実行ファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリードライト) |
| Pleiades 4.3 Kepler | Windowsで実行 |
| x86 Linux MAKE | VMware Player上のx86 Ubuntu Linuxで実行 |
| ARM Linux Cross GCC | VMware Player上のx86 Ubuntu Linuxで実行 |
| ARM Linux Cross GDB←無い | VMware Player上のx86 Ubuntu Linuxで実行 |
| ARM Linux GDBSERVER | CEV-RZ/A1L上のARM Linuxで実行(PCからSSH起動) |
| 実行ファイル | CEV-RZ/A1L上のARM LinuxのGDBSERVERで実行(PC→CEV-RZ/A1LへSSH転送) |
しかしなぜか、CEV Linux SDK V2.00.00ではx86 Linux Host版ARM Linux Cross GDBがありませんでした。
(手違い? ちょっと使い道が想像出来ないx86 Linux Host版ARM Linux Cross GDBSERVERはあるのですが。)
その一方で、CEV-RZ/A1L上で動作するARM Linux GDBはありました。(また、GDBSERVERもありました。)
検索してみると、x86 Linux Host版ARM Linux Cross GDBも他と一緒にビルドされているようでしたが、、、
追記 : メモ
WindowsのPleiades(というかEclipse)が、シンボルの相互参照情報等を作成しようとしてソースコードツリー
全体をスキャンする時に、samba経由でVMware Player上のx86 Ubuntu Linuxのヘッダファイルにアクセス
することが原因で時間が掛かるようになった場合は、Linux側のGCC/Linuxヘッダファイルを丸ごとWindows
側にコピーしてしまうことも考えていました。
| GCC/Linuxヘッダファイル | Linux側とWindows側の両方 (事前にLinux側からWindows側にコピーしておく) |
| GCC/Linuxライブラリ | Linux側 (Windows側からのアクセスは無いと思います) |
| ソースファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリード) |
| 実行ファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリードライト) |
他方、Linux側からVMware Playerのフォルダ共有機能でアクセスするWindows側のフォルダ上にLinux側で
シンボリックリンクを作成出来ない制限があり、それが原因でmakeがコケてしまう場合は、Windows側に
ソースファイル/実行ファイルを置くことを諦め、Linux側にソースファイル/実行ファイルを置くようにして、
WindowsのPleiades(というかEclipse)からsamba経由でアクセスすることも考えていました。
| GCC/Linuxヘッダファイル | Linux側 (Windows側からsamba経由でリード) |
| GCC/Linuxライブラリ | Linux側 (Windows側からのアクセスは無いと思います) |
| ソースファイル | Linux側 (Windows側からsamba経由でリード) |
| 実行ファイル | Linux側 (Windows側からsamba経由でリード) |
さらに、makeがコケてしまう上にシンボルの相互参照情報等を作成しようとしてソースコードツリー全体を
スキャンする時に時間が掛かるようになった場合は、以前のエントリで試してみたEclipseでローカル環境と
リモート環境を同期可能なプラグインを使って、Windows側とLinux側の両方にソースファイルを置いてみる
つもりでした。
| GCC/Linuxヘッダファイル | Linux側とWindows側の両方 (事前にLinux側からWindows側にコピーしておく) |
| GCC/Linuxライブラリ | Linux側 (Windows側からのアクセスは無いと思います) |
| ソースファイル | Windows側とLinux側の両方 (更新時に自動的にWindows側からLinux側にコピー) |
| 実行ファイル | Linux側 (Windows側からsamba経由でリード) |
追記 : 雑感
上の追記に書いた2番目と3番目では、VMware Playerのフォルダ共有機能を使っていません。また、以前の
エントリ(438と460)では、VMware Playerのハードウェア仮想化されたCOMポートを使わなかったことも
あります。両者を組み合わせると、VMware Player固有の機能を使わずにLinux一般の機能だけを使うことに
なりますので、自己流のちょっと変なやり方のリモートビルドとリモートデバッグですが、Raspberry Piや
BeagleBone Blackでも出来そうな気がします。
追記 : 雑感
さらに、Linux MAKE(GNU MAKE)はパラレルビルドが可能ですので、大昔のエントリで以下のように書いた
ことも、サーバーが手配出来れば上の雑感に書いた組み合わせで、ちょっと試せそうな気もします。
'サーバーにファイルを保存したら、サーバー上で勝手にどんどんビルドしてくれる、そんなことが出来ると、
ちょっと面白そうな気がします。それに加え、CPUが何十個も搭載されたサーバーでは、パラレルで一気に
ビルドしてくれるとか、そんなことも出来たら、さらにもうちょっと面白そうな気がします、、、'
2014/06/12 blog-entry-461 category: Pleiades & CrossGCC
Win/Linuxクロス開発 | Pleiades Kepler + VMware Player上のx86 Linux GDBでデバッグ (SSH編)
3つ前のエントリでは、VMware Playerのハードウェア仮想化されたCOMポート経由でWindowsのPleiades 4.3
KeplerからVMware Player上のx86 Linux GDBを実行してみたのですが、今度は、以前のエントリのビルドで
試したようにPuTTYのplink.exeを使ってSSH経由で実行してみました。また、今回は、実行中断用の^Cを入力
することが出来るよう、Pleiadesに同梱されているeclipse.orgのRemote System Explorer(RSE)プラグインの
機能を使い、Pleiades上でSSHターミナルも実行するようにしました。(なお、ビューの自動切り替わりが鬱陶
しかったので、ターミナルビューはメインウィンドウの外へドラッグ&ドロップしました。)
なお、何がどこにあるのか、何がどこで動いているのか、いずれも分かり難いですが、以下のようになります。
修正したファイル: WinLinux.bat
修正前(VMware Playerのハードウェア仮想化されたCOMポート経由版):
rem PATH中にcscript.exeが見つからない場合に備えてPATHにcmd.exeのパス部分を追加
set PATH=%PATH%;%COMSPEC:\cmd.exe=%
rem VMwareのCOMポートでリモートのLinux側のカレントフォルダ変更後にコマンド実行
rem 日本語コードがUnbutu側とWindows/Eclipse側で異なるので英語モードにしておく
if /i %1=='gdb' (
rem GDB起動用のプロセス(真ん中のスクリプト)は早めにecho [[[END]]]で終わらせる
cscript -nologo "%~dp0\vmwshdo2.js" \\.\pipe\vmware-serial-port2 | cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; cd '%LINUXPATH%' ; echo [[[END]]] ; %LINUXARGS% ^< /dev/ttyS2 ^> /dev/ttyS3 | cscript -nologo "%~dp0\vmwshdo3.js" \\.\pipe\vmware-serial-port3
) else if /i %1=='gdbserver' (
cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; echo cd '%LINUXPATH%' ^> ~/wlshdo.p ; echo %LINUXARGS% ^> ~/wlshdo.p
) else if exist "%~dp0\%CMDNAME%_outputconv.js" (
cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS% | cscript -nologo "%~dp0\%CMDNAME%_outputconv.js"
) else (
cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS%
)
修正後(PuTTYのplink.exeを使ったSSH経由版):
rem PATH中にcscript.exeが見つからない場合に備えてPATHにcmd.exeのパス部分を追加
rem PATH中にplink.exeが見つからない場合(GDB起動時)に備えてPATH設定を応急処置
↓ 追記 : 以下1行変更しました。(2014/06/22)
set PATH=%PATH%;%COMSPEC:\cmd.exe=%;E:\utils\putty
set PATH=%PATH%;%COMSPEC:\cmd.exe=%;Z:\WinTools\PuTTY
rem Puttyのplink.exeでリモートのLinux側のカレントフォルダ変更後にコマンド実行
rem 日本語コードがUnbutu側とWindows/Eclipse側で異なるので英語モードにしておく
if /i %1=='gdb' (
rem なぜかGDB実行用のplink.exeに-tを付けるとEclipseのコンソールにMIコマンドが表示されるので付けない
cscript -nologo "%~dp0\vmwshdo12.js" | plink ubuntu@ubuntu -pw ubuntu LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS% | cscript -nologo "%~dp0\vmwshdo13.js"
) else if /i %1=='gdbserver' (
plink ubuntu@ubuntu -pw ubuntu -t LANG=en_US ; echo cd '%LINUXPATH%' ^> ~/wlshdo.p ; echo %LINUXARGS% ^> ~/wlshdo.p
) else if exist "%~dp0\%CMDNAME%_outputconv.js" (
plink ubuntu@ubuntu -pw ubuntu -t LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS% | cscript -nologo "%~dp0\%CMDNAME%_outputconv.js"
) else (
plink ubuntu@ubuntu -pw ubuntu -t LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS%
)
追加したファイル: vmwshdo12.js (標準入力をPuttyのplink.exeの入力へパス変換&転送)
// This code is in the public domain. You may use, modify or distribute it freely.
var stdin, pipeout, pipein, stdout, str;
// ★★★★メンテしやすい方法へ要修正★★★★
var WindowsPath = /Z:\/home\/ubuntu/g;
var UbuntuPath = "/home/ubuntu";
stdin = WScript.StdIn;
pipeout = WScript.StdOut;
while(1)
{
while( stdin.AtEndOfStream )
{
WScript.Sleep(100); // ms
}
str =stdin.ReadLine();
// パス区切り文字を変更する
str = str.replace(/\\\\/g, "/");
// Windows側→Ubuntu側のパス変換を行う(やり方が非常に荒っぽい)
str = str.replace(WindowsPath, UbuntuPath);
pipeout.WriteLine(str);
// GDB終了メッセージを検出したら終了する
if (str.search(/^[0-9][0-9]*-gdb-exit$/) != -1)
{
// 終了
break;
}
}
WScript.Quit(0)
追加したファイル: vmwshdo13.js (Puttyのplink.exeの出力をパス変換&標準出力へ転送)
// This code is in the public domain. You may use, modify or distribute it freely.
var stdin, pipeout, pipein, stdout, str;
// ★★★★メンテしやすい方法へ要修正★★★★
var UbuntuPath = /\/home\/ubuntu/g;
var WindowsPath = "Z:/home/ubuntu";
stdout = WScript.StdOut;
pipein = WScript.StdIn;
while(1)
{
while( pipein.AtEndOfStream )
{
WScript.Sleep(100); // ms
}
str = pipein.ReadLine();
// Ubuntu側→Windows側のパス変換を行う(やり方が非常に荒っぽい)
str = str.replace(UbuntuPath, WindowsPath);
stdout.WriteLine(str);
// GDB終了メッセージを検出したら終了する
if (str.search(/^[0-9][0-9]*\^exit$/) != -1)
{
// 終了
break;
}
}
WScript.Quit(0)
KeplerからVMware Player上のx86 Linux GDBを実行してみたのですが、今度は、以前のエントリのビルドで
試したようにPuTTYのplink.exeを使ってSSH経由で実行してみました。また、今回は、実行中断用の^Cを入力
することが出来るよう、Pleiadesに同梱されているeclipse.orgのRemote System Explorer(RSE)プラグインの
機能を使い、Pleiades上でSSHターミナルも実行するようにしました。(なお、ビューの自動切り替わりが鬱陶
しかったので、ターミナルビューはメインウィンドウの外へドラッグ&ドロップしました。)
なお、何がどこにあるのか、何がどこで動いているのか、いずれも分かり難いですが、以下のようになります。
| GCC/Linuxヘッダファイル | Linux側 (Windows側からsamba経由でリード) |
| GCC/Linuxライブラリ | Linux側 (Windows側からのアクセスは無いと思います) |
| ソースファイル | Windows側 (今回はLinux側からのアクセスは無いと思います) |
| 実行ファイル | Windows側 (Linux側からVMware Playerのフォルダ共有機能経由でリード) |
| Pleiades 4.3 Kepler | Windowsで実行 |
| x86 Linux GDB | VMware Player上のx86 Ubuntu Linuxで実行 |
| x86 Linux GDBSERVER | VMware Player上のx86 Ubuntu Linuxで実行 |
| 実行ファイル | VMware Player上のx86 Ubuntu LinuxのGDBSERVERで実行 |
修正したファイル: WinLinux.bat
修正前(VMware Playerのハードウェア仮想化されたCOMポート経由版):
rem PATH中にcscript.exeが見つからない場合に備えてPATHにcmd.exeのパス部分を追加
set PATH=%PATH%;%COMSPEC:\cmd.exe=%
rem VMwareのCOMポートでリモートのLinux側のカレントフォルダ変更後にコマンド実行
rem 日本語コードがUnbutu側とWindows/Eclipse側で異なるので英語モードにしておく
if /i %1=='gdb' (
rem GDB起動用のプロセス(真ん中のスクリプト)は早めにecho [[[END]]]で終わらせる
cscript -nologo "%~dp0\vmwshdo2.js" \\.\pipe\vmware-serial-port2 | cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; cd '%LINUXPATH%' ; echo [[[END]]] ; %LINUXARGS% ^< /dev/ttyS2 ^> /dev/ttyS3 | cscript -nologo "%~dp0\vmwshdo3.js" \\.\pipe\vmware-serial-port3
) else if /i %1=='gdbserver' (
cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; echo cd '%LINUXPATH%' ^> ~/wlshdo.p ; echo %LINUXARGS% ^> ~/wlshdo.p
) else if exist "%~dp0\%CMDNAME%_outputconv.js" (
cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS% | cscript -nologo "%~dp0\%CMDNAME%_outputconv.js"
) else (
cscript -nologo "%~dp0\vmwshdo.js" \\.\pipe\vmware-serial-port LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS%
)
修正後(PuTTYのplink.exeを使ったSSH経由版):
rem PATH中にcscript.exeが見つからない場合に備えてPATHにcmd.exeのパス部分を追加
rem PATH中にplink.exeが見つからない場合(GDB起動時)に備えてPATH設定を応急処置
↓ 追記 : 以下1行変更しました。(2014/06/22)
set PATH=%PATH%;%COMSPEC:\cmd.exe=%;Z:\WinTools\PuTTY
rem Puttyのplink.exeでリモートのLinux側のカレントフォルダ変更後にコマンド実行
rem 日本語コードがUnbutu側とWindows/Eclipse側で異なるので英語モードにしておく
if /i %1=='gdb' (
rem なぜかGDB実行用のplink.exeに-tを付けるとEclipseのコンソールにMIコマンドが表示されるので付けない
cscript -nologo "%~dp0\vmwshdo12.js" | plink ubuntu@ubuntu -pw ubuntu LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS% | cscript -nologo "%~dp0\vmwshdo13.js"
) else if /i %1=='gdbserver' (
plink ubuntu@ubuntu -pw ubuntu -t LANG=en_US ; echo cd '%LINUXPATH%' ^> ~/wlshdo.p ; echo %LINUXARGS% ^> ~/wlshdo.p
) else if exist "%~dp0\%CMDNAME%_outputconv.js" (
plink ubuntu@ubuntu -pw ubuntu -t LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS% | cscript -nologo "%~dp0\%CMDNAME%_outputconv.js"
) else (
plink ubuntu@ubuntu -pw ubuntu -t LANG=en_US ; cd '%LINUXPATH%' ; %LINUXARGS%
)
追加したファイル: vmwshdo12.js (標準入力をPuttyのplink.exeの入力へパス変換&転送)
// This code is in the public domain. You may use, modify or distribute it freely.
var stdin, pipeout, pipein, stdout, str;
// ★★★★メンテしやすい方法へ要修正★★★★
var WindowsPath = /Z:\/home\/ubuntu/g;
var UbuntuPath = "/home/ubuntu";
stdin = WScript.StdIn;
pipeout = WScript.StdOut;
while(1)
{
while( stdin.AtEndOfStream )
{
WScript.Sleep(100); // ms
}
str =stdin.ReadLine();
// パス区切り文字を変更する
str = str.replace(/\\\\/g, "/");
// Windows側→Ubuntu側のパス変換を行う(やり方が非常に荒っぽい)
str = str.replace(WindowsPath, UbuntuPath);
pipeout.WriteLine(str);
// GDB終了メッセージを検出したら終了する
if (str.search(/^[0-9][0-9]*-gdb-exit$/) != -1)
{
// 終了
break;
}
}
WScript.Quit(0)
追加したファイル: vmwshdo13.js (Puttyのplink.exeの出力をパス変換&標準出力へ転送)
// This code is in the public domain. You may use, modify or distribute it freely.
var stdin, pipeout, pipein, stdout, str;
// ★★★★メンテしやすい方法へ要修正★★★★
var UbuntuPath = /\/home\/ubuntu/g;
var WindowsPath = "Z:/home/ubuntu";
stdout = WScript.StdOut;
pipein = WScript.StdIn;
while(1)
{
while( pipein.AtEndOfStream )
{
WScript.Sleep(100); // ms
}
str = pipein.ReadLine();
// Ubuntu側→Windows側のパス変換を行う(やり方が非常に荒っぽい)
str = str.replace(UbuntuPath, WindowsPath);
stdout.WriteLine(str);
// GDB終了メッセージを検出したら終了する
if (str.search(/^[0-9][0-9]*\^exit$/) != -1)
{
// 終了
break;
}
}
WScript.Quit(0)
2014/06/10 blog-entry-460 category: Pleiades & CrossGCC
Win/Linuxクロス開発 | Pleiades Kepler + VMware Player上のx86 Linux GDBでデバッグ (7)→×
2つ前のエントリで、Pleiades 4.3 KeplerからVMware Player上のx86 Linux GDBを起動させて事前に自動起動
させておいたGDBSERVERと接続するようにしたのですが、Pleiades 4.3 KeplerからGDBSERVERに接続する
GDBを起動する選択肢は、他にも1つあります。(Pleiadesにeclipse.orgのC/C++ GDB Hardware Debugging
プラグインをインストールすると、更にあと2つ増えます。) ですが、試してみたところ、以下の問題が発生して
しまい、実用にはなりませんでした。
* 設定したブレークポイントで停止しない
* Pleiades上でアプリケーションを実行中断させる操作を行うと、PleiadesとVMware Player上のx86 Linux
GDBとの通信を中継しているバッチファイルやスクリプトファイル(自作のgdb.batをEXE化したgdb.exe内
から呼び出しているWinLinux.batやvmwshdo2.jsやvmwshdo3.js)が強制終了してしまい、以後、Linux
上のGDBやGDBSERVERを制御出来なくなる (結果、Linxu上で起動されたGDBやGDBSERVERがゾンビ化
してしまい、手作業でkillしなければならなくなる)
GDBSERVERに接続するGDBを起動するもう1つの選択肢
しかし、設定したブレークポイントで停止しなかったり、、、
Pleiades上でアプリケーションを実行中断させる操作を行うと強制終了してしまったり、、、
GDBやGDBSERVERがゾンビ化してしまった場合には、以下のように手作業でkillしなければならなくなります。
させておいたGDBSERVERと接続するようにしたのですが、Pleiades 4.3 KeplerからGDBSERVERに接続する
GDBを起動する選択肢は、他にも1つあります。(Pleiadesにeclipse.orgのC/C++ GDB Hardware Debugging
プラグインをインストールすると、更にあと2つ増えます。) ですが、試してみたところ、以下の問題が発生して
しまい、実用にはなりませんでした。
* 設定したブレークポイントで停止しない
* Pleiades上でアプリケーションを実行中断させる操作を行うと、PleiadesとVMware Player上のx86 Linux
GDBとの通信を中継しているバッチファイルやスクリプトファイル(自作のgdb.batをEXE化したgdb.exe内
から呼び出しているWinLinux.batやvmwshdo2.jsやvmwshdo3.js)が強制終了してしまい、以後、Linux
上のGDBやGDBSERVERを制御出来なくなる (結果、Linxu上で起動されたGDBやGDBSERVERがゾンビ化
してしまい、手作業でkillしなければならなくなる)
GDBSERVERに接続するGDBを起動するもう1つの選択肢
しかし、設定したブレークポイントで停止しなかったり、、、
Pleiades上でアプリケーションを実行中断させる操作を行うと強制終了してしまったり、、、
GDBやGDBSERVERがゾンビ化してしまった場合には、以下のように手作業でkillしなければならなくなります。
2014/06/08 blog-entry-459 category: Pleiades & CrossGCC
Win/Linuxクロス開発 | Pleiades Kepler + VMware Player上のx86 Linux GDBでデバッグ (6)→×
前のエントリで、Pleiades 4.3 KeplerからVMware Player上のx86 Linux GDBSERVERを自動起動させるのに、
EclipseのLaunch Group機能を使用してみたのですが、そもそも、Eclipseの[デバッグ構成]ダイアログには、
いかにもGDBSERVERを自動起動させるのに使えそうな選択肢が2つあります。しかし、残念ながら、2つとも
エラーが発生してしまい、使えませんでした。
GDBSERVERを自動起動させるのに使えそうな2つの選択肢
しかし、2つともエラーが発生
Windowsのタスクマネージャーを見てみた時の印象では、どうも以下のような感じがしました。
* 1つ目の選択肢では、GDBSERVERを起動しようとしている気配が全く無い
* 2つ目の選択肢では、'cmd /C cmd'を実行しようとして、前側のcmdの実行には成功しているものの、
後側(引数側)のcmdの実行に失敗している (成功していれば、この後、標準入力経由でGDBSERVER
起動コマンドが送り込まれるようになっているのかも知れません)
ちなみに2つ目の選択肢ですが、今回はローカル環境側から間接的にリモート環境のVMware Player上のx86
Linux GDBSERVERを起動しようとして失敗したのですが、以前には直接リモート環境のVMware Player上の
x86 Linux GDBSERVERを起動しようとして起動出来たことがあります。
ローカル環境側から間接的にGDBSERVER起動しようとして失敗した設定(今回)
直接リモート環境のGDBSERVER起動しようとして成功した設定(以前)
EclipseのLaunch Group機能を使用してみたのですが、そもそも、Eclipseの[デバッグ構成]ダイアログには、
いかにもGDBSERVERを自動起動させるのに使えそうな選択肢が2つあります。しかし、残念ながら、2つとも
エラーが発生してしまい、使えませんでした。
GDBSERVERを自動起動させるのに使えそうな2つの選択肢
しかし、2つともエラーが発生
Windowsのタスクマネージャーを見てみた時の印象では、どうも以下のような感じがしました。
* 1つ目の選択肢では、GDBSERVERを起動しようとしている気配が全く無い
* 2つ目の選択肢では、'cmd /C cmd'を実行しようとして、前側のcmdの実行には成功しているものの、
後側(引数側)のcmdの実行に失敗している (成功していれば、この後、標準入力経由でGDBSERVER
起動コマンドが送り込まれるようになっているのかも知れません)
ちなみに2つ目の選択肢ですが、今回はローカル環境側から間接的にリモート環境のVMware Player上のx86
Linux GDBSERVERを起動しようとして失敗したのですが、以前には直接リモート環境のVMware Player上の
x86 Linux GDBSERVERを起動しようとして起動出来たことがあります。
ローカル環境側から間接的にGDBSERVER起動しようとして失敗した設定(今回)
直接リモート環境のGDBSERVER起動しようとして成功した設定(以前)
2014/06/07 blog-entry-458 category: Pleiades & CrossGCC
