☰

Backtrace von „Git-Klon“, der in einem auf QEMU-Benutzeremulation basierenden Arm-Chroot ausgeführt wird

tag-icon • tag-icon chroot dpkg qemu gdb multiarch
Backtrace von „Git-Klon“, der in einem auf QEMU-Benutzeremulation basierenden Arm-Chroot ausgeführt wird

Ich führe ein wheezy:armhf chroot mitQEMU-Benutzeremulationauf meinem System jessie:x86_64. Irgendwie git clonebleibt ein in einem bestimmten privaten Repository im Chroot hängen, während es nativ erfolgreich ist. Das könnte ein Fehler sein, wer weiß? Um mein Karma zu verbessern, möchte ich herausfinden, was los ist!

Als Randbemerkung: Der Hänger, den ich erlebe, tritt auch mit git-2.0 innerhalb von jessie:armel chroot auf... Der Hänger tritt nicht innerhalb einer Vollsystem-Emulation auf. Also habe ich weiter in denkeuchend:armhfKaninchenbau, nur weil ich eines auswählen musste … Ich kann nicht auf einer nativen Maschine testen …

Also. Es gibt kein git-dbgPaket, ich baue mein eigenes. Innerhalb des wheezy:armhf-Chroots:

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

Soweit ich gelesen habe,gcc-dokumentation, die Einstellung DEB_CFLAGS_APPENDund DEB_CXXFLAGS_APPENDzusätzlich mit -fno-stack-protectorist nicht erforderlich, aber ich möchte trotzdem sichergehen)

Dann verwenden Sie qemu's eingebautegdb_stubinnerhalb des Chroots mache ich:

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

Beim Debuggen innerhalb von QEMU tritt einnicht unterstütztes Syscal 26Fehler.

So starten Sie gdb-multiarchdie Verbindung außerhalb des Chroot:

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?

Wenn Sie ein geben continue, um den Klonvorgang zuzulassen, kommt es zum Hängenbleiben. Das Senden eines ctrl-c wird ignoriert.

Wenn ich eine Core-Datei erzeuge und sie in gdb (innerhalb des Chroot) lade, erhalte ich einen beschädigten Stack:

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?)

Jetzt bin ich verloren.

Wo liegt das Problem? Habe ich ein Detail bei der QEMU-Benutzeremulation übersehen? Muss ich eine vollständig emulierte Arm-Maschine verwenden? Ein Missverständnis beim Cross-Debugging? GDB-Multiarch-Einschränkungen? Die Erstellung von Debug-Paketen?

Vielen Dank für alle Vorschläge, Hinweise, Tipps, Kommentare usw.

Meine beste Vermutung im Moment basiert auf der Tatsache, dass gitein Klon erstellt wird (ich kann zwei Prozesse/Threads sehen), aber die QEMU_GDBUmgebungsvariable wird von qemu nach der Verwendung gelöscht. Daher geht nur der anfängliche Prozess zu gdb. SieheHierZum Beispiel.

Aber trotzdem: Ich sollte in der Lage sein, den übergeordneten Prozess ordnungsgemäß zu debuggen? Ich kann ein „Hello World“-MWE problemlos plattformübergreifend debuggen.

Antwort1

Es stellte sich heraus, dass dieses spezielle Hängenbleiben von „Git-Klon“ ein QEMU-bezogenes Problem ist … Es bestehen andere Probleme bei der QEMU-Benutzeremulation, sodass ich auf die Vollsystememulation zurückgreifen muss … ;-(

Unter Verwendung eines qemu-user-static, kompiliert aus ihrem Git (das derzeit in Jessie vorhandene qemu-2.0.0+dfsg-4+b1 hat weniger Korrekturen und funktioniert in meinem Fall nicht...):

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

Also...

Ich kann jedoch immer noch keinen Backtrace komplexer Programme abrufen ...

verwandte Informationen