Я запускаю wheezy:armhf chroot с помощьюэмуляция пользователя qemuна моей системе jessie:x86_64. Каким-то образом, a git cloneна определенном частном репозитории зависнет внутри chroot, хотя нативно будет успешно выполнено. Это может быть баг, кто знает? Чтобы улучшить свою карму, я хочу узнать, что происходит!
В качестве примечания: зависание, которое я испытываю, происходит также с git-2.0 внутри chroot jessie:armel... Зависание не происходит внутри полной эмуляции системы. Поэтому я продолжил копаться вхриплый:armhfкроличья нора, просто потому что мне пришлось выбрать что-то одно... Я не могу протестировать на родной машине...
Так. Пакета нет 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_stubвнутри chroot я делаю:
QEMU_GDB=1234 git clone /path/to/breaking/repo /tmp/bla
Отладка внутри QEMU выдает ошибкунеподдерживаемый syscal 26ошибка.
Запуск gdb-multiarchвне 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?
Отправка , continueчтобы разрешить клонирование, приведет к зависанию, отправка ctrl-c игнорируется.
Генерация core-файла и загрузка его в 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делает клон (я вижу два процесса/потока), но QEMU_GDBпеременная окружения сбрасывается qemu после использования. Следовательно, только начальный процесс отправляется в gdb. Смотритездесьнапример.
Но все же: я должен иметь возможность правильно отлаживать родительский процесс? Я могу легко перекрестно отлаживать hello-world MWE.
решение1
Оказывается, эта конкретная проблема с «git clone» связана с qemu... Преобладают другие проблемы в qemu-user-emulation, поэтому мне приходится возвращаться к полной эмуляции системы... ;-(
Используя qemu-user-static, скомпилированный из их git (qemu-2.0.0+dfsg-4+b1, который сейчас находится в jessie, имеет меньше исправлений и не будет работать в моем случае...):
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
так...
Однако я все еще не могу получить трассировку сложных программ...