☰

qemu-user-emulation ベースの arm-chroot 内で実行されている「git clone」のバックトレース

tag-icon • tag-icon chroot dpkg qemu gdb multiarch
qemu-user-emulation ベースの arm-chroot 内で実行されている「git clone」のバックトレース

私はwheezy:armhf chrootを実行していますqemu ユーザーエミュレーション私の jessie:x86_64 システムで。どういうわけか、git clone特定のプライベート リポジトリでは、ネイティブでは成功しているのに、chroot 内でハングします。これはバグかもしれません。誰にもわかりません。カルマを向上させるために、何が起こっているのかを知りたいです。

補足：私が経験しているハングは、git-2.0のjessie:armel chroot内でも発生しています。このハングはフルシステムエミュレーション内では発生しません。そこで、喘鳴:armhfrabbithole、1つを選択しなければならなかったので...ネイティブマシンでテストできません...

ということで、パケットはないのでgit-dbg、自分で作成します。wheezy:armhf chroot 内:

sudo apt-get install build-essential fakeroot
sudo apt-get build-dep git
apt-get source git && cd git-1.7.10.4
DEB_CFLAGS_APPEND="-fno-stack-protector" DEB_CXXFLAGS_APPEND="-fno-stack-protector" DEB_BUILD_MAINT_OPTIONS=hardening=-stackprotector,-fortify DEB_BUILD_OPTIONS="noopt nostrip nocheck" fakeroot dpkg-buildpackage -j´getconf _NPROCESSORS_ONLN`
sudo dpkg -i ../git_1.7.10.4-1+wheezy1_armhf.deb

私が読んだ限りではgcc ドキュメント、設定DEB_CFLAGS_APPENDやDEB_CXXFLAGS_APPEND追加は-fno-stack-protector必要ありませんが、とにかく確認したいです）

次に、qemuの組み込みgdb_スタブchroot 内では以下を実行しています:

QEMU_GDB=1234 git clone /path/to/breaking/repo /tmp/bla

qemu内でデバッグすると、サポートされていないシステム カル 26エラー。

gdb-multiarchchroot の外で起動して接続します:

gdb-multiarch -q
(gdb) set architecture arm                    # prevents "warning: Architecture rejected target-supplied description"
(gdb) target remote localhost:1234
(gdb) set sysroot /opt/chroots/wheezy:armhf
(gdb) file /opt/chroots/wheezy:armhf/usr/bin/git
Reading symbols from /opt/chroots/wheezy:armhf/usr/bin/git...done. # good! has debug symbols!
(gdb) list                                    # works! code is not stripped
(gdb) step
Cannot find bounds of current function        # meh...
(gdb) backtracke
#0  0xf67e0c90 in ?? ()
#1  0x00000000 in ?? ()                       # wtf?

クローンを実行するためにを与えるcontinueとハングアップし、 の送信はctrl-c 無視されます。

コア ファイルを生成し、それを gdb (chroot 内) にロードすると、スタックが破損します。

gdb -q /usr/bin/git qemu_git_20140514-160951_22373.core
Reading symbols from /usr/bin/git...done.
[New LWP 22373]
Cannot access memory at address 0xf67fe948
Cannot access memory at address 0xf67fe944
(gdb) bt
#0  0xf678b3e4 in ?? ()
#1  0xf678b3d4 in ?? ()
#2  0xf678b3d4 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

今、私は迷っています。

問題はどこにありますか? qemu-user-emulation の詳細を見逃しましたか? 完全にエミュレートされた arm マシンを使用する必要がありますか? クロスデバッグの誤解ですか? gdb-multiarch の制限ですか? デバッグ パッケージの作成ですか?

ご提案、ご指摘、ヒント、アドバイス、コメントなど何でも結構です。

git現時点での私の推測は、クローンを実行する（2つのプロセス/スレッドが見える）という事実に基づいていますが、QEMU_GDB使用後にqemuによって環境変数が設定されていません。したがって、最初のプロセスのみがgdbに行きます。ここ例えば。

しかし、それでも、親プロセスを適切にデバッグできるはずです。hello-world MWE は簡単にクロスデバッグできます。

答え1

結局、この「git clone」のハングは qemu 関連の問題であることがわかりました... qemu ユーザー エミュレーションの他の問題が優先されるため、フル システム エミュレーションにフォールバックする必要があります... ;-(

git からコンパイルされたを使用しますqemu-user-static(現在 jessie にある qemu-2.0.0+dfsg-4+b1 には修正が少なく、私のケースでは動作しません...):

git clone git://git.qemu-project.org/qemu.git $HOME/qemu.git && cd $HOME/qemu.git
./configure --static --disable-system --target-list=arm-linux-user --prefix=$HOME/qemu.install --disable-libssh2
make && make install
sudo cp $HOME/qemu.install/bin/qemu-arm /opt/chroots/wheezy:armhf/usr/bin/qemu-arm-static

それで...

しかし、複雑なプログラムのバックトレースはまだ取得できません...

関連情報