shun
2024年12月18日 14時56分
==========
製品型番：Armadillo-610
Debian/ABOSバージョン：3.19.2-at.5
カーネルバージョン：Linux armadillo 5.10.220 #1 Mon Nov 11 18:22:24 JST 2024 armv7l Linux
その他：U-Boot 2020.04-at24 (Jun 25 2024 - 05:19:56 +0000)
==========
https://armadillo.atmark-techno.com/forum/armadillo/22651#comment-18274
↑のフォーラムでGDBを使ったデバッグをしているのですが、疑問点があったので質問します。
GDBのデバッグ環境のファイルシステムと、swuインストールしたArmadillo-610のファイルシステムが異なっているのですが、どういった違いがあるのでしょうか？
具体的には、/vol_app/や/vol_data/といったディレクトリがArmadillo-610のルートディレクトリにはありません。
ご回答いただけると幸いです。
コメント
shun
お世話になっております。
ご回答ありがとうございます。GDBデバッグ環境からはコンテナ内にボリュームマウントされたディレクトリを参照しているということですね。
現在[/dev/ttyACM0]を使用してシリアル通信をしたいと思っております。
Armadillo-610本体には[/dev/ttyACM0]のデバイスファイルが存在するのですが、GDBのデバッグ環境にはそのディレクトリはありませんでした。
同じルート名でArmadillo本体に参照したい場合、
add_devices /dev/ttyACM0 /dev/ttyACM0
このような記述をapp.confに追記すればよいでしょうか？
ご回答の程よろしくお願いいたします。
at_reika.yamazaki
shun
お世話になっております。
app.conf: [add_devices /dev/ttyACM0]
に追記したところでシリアル通信が可能になりました。ありがとうございます。
一点別の質問があります。
現在、C言語ソース[.c]からディレクトリ内にあるシェルスクリプト[.sh]を実行するために「system関数」を使用しております。
しかし、実行しても正常な動作をせず終了してしまいます。
system関数を使用するにあたって必要な設定等はありますでしょうか？
ご回答の程よろしくお願いいたします。
以下、ソースコードと実行結果です。
==ソースコード==
printf("COM: %s\n", cachCommand);
iSysRet = system(cachCommand);
printf("iSysRet: %d\n", iSysRet);
==実行結果(gdbの応答)==
COM: /vol_app/build/FileCheck.sh /vol_data/ABC.txt
[Detaching after vfork from child process 9]
iSysRet: 256at_reika.yamazaki
お世話になっております。山崎です。
エラーの内容を調べたところ、GDB がどのプロセスを選択しているときに出すメッセージらしいです。
以下のコマンドを使うとフォーク時にデタッチするプロセスを設定することができるとのことです。
https://visualgdb.com/gdbreference/commands/set_detach-on-fork
もしかすると "set detach-on-fork off" を設定するとうまくいくかもしれません。
ちなみになのですが、これまでコンテナ外からは GDB 実行での system 関数の呼び出しは問題なかったのでしょうか？
以上、どうぞよろしくお願いいたします。
shun
お世話になっております。
"set detach-on-fork off" で設定してGDB実行したのですが、以下のような箇所で停止してしまいました。
Breakpoint 1, FUNC(
~~~
(gdb) show detach-on-fork
show detach-on-fork
Whether gdb will detach the child of a fork is on.
(gdb) set detach-on-fork off
set detach-on-fork off
(gdb) show detach-on-fork
show detach-on-fork
Whether gdb will detach the child of a fork is off.
(gdb) n
n
Can not resume the parent process over vfork in the foreground while
holding the child stopped. Try "set detach-on-fork" or "set schedule-multiple".
clone () at ../sysdeps/unix/sysv/linux/arm/clone.S:58
58 ../sysdeps/unix/sysv/linux/arm/clone.S: No such file or directory.
(gdb) これまでは GDB 実行での system 関数の呼び出しは問題なかったです。
iSysRet = 0でそのまま次の処理は実行できていました。
以上、よろしくお願いいたします。
at_reika.yamazaki
shun
お世話になっております。
説明不足で申し訳ありません。
gdb上で"set detach-on-fork off"を実行したのち、system関数を実行するときに以下の箇所で停止してしまう状態です。
Breakpoint 1, FUNC(
~~~
(gdb) set detach-on-fork off
set detach-on-fork off
(gdb) c
c
Continuing.
Can not resume the parent process over vfork in the foreground while
holding the child stopped. Try "set detach-on-fork" or "set schedule-multiple".
clone () at ../sysdeps/unix/sysv/linux/arm/clone.S:58
58 ../sysdeps/unix/sysv/linux/arm/clone.S: No such file or directory.
(gdb) c
c
Continuing.
Can not resume the parent process over vfork in the foreground while
holding the child stopped. Try "set detach-on-fork" or "set schedule-multiple".
clone () at ../sysdeps/unix/sysv/linux/arm/clone.S:58
58 in ../sysdeps/unix/sysv/linux/arm/clone.S
(gdb) c
c
Continuing.
Can not resume the parent process over vfork in the foreground while
holding the child stopped. Try "set detach-on-fork" or "set schedule-multiple".
clone () at ../sysdeps/unix/sysv/linux/arm/clone.S:58
58 in ../sysdeps/unix/sysv/linux/arm/clone.S
(gdb)
↑以降ループ> この iSysRet = 0 はデバッグを進めると表示される文字列ということでしょうか？
その通りです。printf関数で"iSysRet"の内容を表示するようにしています。
以下に、"set detach-on-fork on"の状態で、system関数が問題なく実行される処理の動きを示します。
<<system関数が問題なく処理できるとき>>
Breakpoint 1, FUNC(
~~~
(gdb) c
c
Continuing.
[Detaching after vfork from child process 23]
iSysRet:0
~~~
[Inferior 1 (process 20) exited normally]
(gdb)
<<system関数が異常処理のとき>>
Breakpoint 1, FUNC(
~~~
(gdb) c
c
Continuing.
[Detaching after vfork from child process 33]
iSysRet:256
~~~
[Inferior 1 (process 30) exited with code 0377]以上、よろしくお願いいたします。
at_reika.yamazaki
お世話になっております。山崎です。
>gdb上で"set detach-on-fork off"を実行したのち、system関数を実行するときに以下の箇所で停止してしまう状態です。
了解です。でしたら "set detach-on-fork off" は不要で、"set detach-on-fork on" の状態で問題ないと思います。
コメントを見返していたところ、以下のコメントでは iSysRet: 256 の値が取れているように思います。
https://armadillo.atmark-techno.com/forum/armadillo/23437#comment-18556
"set detach-on-fork on" の状態であればデバッグは進むという認識で相違ないでしょうか？
だとすると、デバッグについては問題ないと思うのですが、「実行しても正常な動作をせず終了してしまいます。」とおっしゃっているのは GDB デバッグの動作ではなく、ご使用のプログラムの処理ということでよろしいでしょうか？
追加で確認なのですが、ご使用のプログラムでは /vol_data/ABC.txt のようなファイルを作成するのだと思います。
こちらのファイルは Cのプログラムで作成されていると思うのですが、/vol_data/ABC.txt は作成されているでしょうか？
デフォルトの C言語プロジェクトでは /var/app/volumes/{{PROJECT}} を /vol_data にボリュームマウントしているため、コンテナ外からでも確認できると思います。
以上、確認です。
どうぞよろしくお願いいたします。
shun
お世話になっております。
> "set detach-on-fork on" の状態であればデバッグは進むという認識で相違ないでしょうか？
話が紛らわしくなり申し訳ありません。
デバッグ自体は問題なくできるのですが、system関数の実行において問題が発生している状態です。
> 追加で確認なのですが、ご使用のプログラムでは /vol_data/ABC.txt のようなファイルを作成するのだと思います。
> こちらのファイルは Cのプログラムで作成されていると思うのですが、/vol_data/ABC.txt は作成されているでしょうか？
iSysRet = system(cachCommand);
printf("iSysRet: %d\n", iSysRet);上記のようなプログラムで、
① iSysRet:0の応答のとき
→/vol_data/ABC.txtは作成。
② iSysRet:256の応答のとき
→/vol_data/ABC.txtは未作成。※①とは別の.txt
system関数を使用するにあたってABOS DE上で必要な設定等はございますでしょうか。
以上、よろしくお願いいたします。
at_reika.yamazaki
お世話になっております。山崎です。
こちらでも簡単な C プログラムを作成して試してみました。
こちらのプログラムでは同様に、system 関数を用いて /vol_data/ABC.txt を作成するシェルスクリプトを呼び出しています。
結果としてファイルは作成されておりコンテナ内で system 関数を使用するのに追加の設定は必要ないと思われます。
加えて GDB デバッグ実行もしてみましたが、iSysRet: 0 が返ってきており、ファイルの作成にも成功しています。
(gdb) run run Starting program: /vol_app/build/main warning: Error disabling address space randomization: Success Breakpoint 1, main () at main.c:9 9 main.c: No such file or directory. (gdb) c c Continuing. COM: /vol_app/build/FileCheck.sh [Detaching after vfork from child process 51] iSysRet: 0
上記から、ファイルが作成されないのは別の要因であると考えられます。
まずは、ご使用のシェルスクリプトを system 関数は使わず、直接実行した場合は成功するかどうか確認をお願いします。
失敗する場合はシェルスクリプトのどこで失敗しているか、ログを追加して確認いただくのが良いと思います。
以上、どうぞよろしくお願いいたします。
at_reika.yamazaki
2024年12月18日 18時03分
お世話になっております。山崎です。
>swuインストールしたArmadillo-610のファイルシステム
こちらは以下にある Armadillo-610用 SWUイメージファイルをご使用になったということで相違ないでしょうか？
https://armadillo.atmark-techno.com/resources/software/armadillo-610/ba…
こちらに対して、GDBのデバッグ環境のファイルシステムというのは ABOSDE で開発した C言語プロジェクトでインストールしたコンテナ内だと思います。
この C言語プロジェクトの config/app.conf に以下の記述があると思います。
add_volumes {{PROJECT}}:/vol_app add_volumes /var/app/volumes/{{PROJECT}}:/vol_dataこれは ABOS 上のディレクトリをコンテナ内にマウントする記述になります。
この記述により、コンテナ内ではボリュームマウントされた /vol_app や /vol_data ディレクトリが現れて、アクセスできるようになります。
また、ボリュームマウントすることにより、コンテナ内で作成されたファイルに ABOS 上からアクセス出来たりといったことが可能になります。
他、疑問点等ありましたら仰ってください。
以上、どうぞよろしくお願いいたします。