나는 다음을 사용하여 wheezy:armhf chroot를 실행하고 있습니다.qemu 사용자 에뮬레이션내 jessie:x86_64 시스템에서요. 어쨌든 git clone특정 개인 저장소의 a는 chroot 내부에 정지되지만 기본적으로 성공합니다. 이것은 버그일지도 모릅니다. 누가 알겠습니까? 업장을 개선하기 위해 무슨 일이 일어나고 있는지 알고 싶습니다!
참고로 제가 겪고 있는 정지 현상은 jessie:armel chroot 내부의 git-2.0에서도 발생합니다... 전체 시스템 에뮬레이션 내에서는 정지 현상이 발생하지 않습니다. 그래서 계속해서 파헤쳐봤죠쌕쌕거림:armhfRabbithole, 하나만 선택해야 했기 때문에... 기본 머신에서는 테스트할 수 없습니다...
그래서. 패킷 이 없습니다 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-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복제가 발생하도록 a를 제공하면 중단이 발생하고 a를 보내면 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-machine을 사용해야 합니까? 크로스 디버깅에 대한 오해? gdb-multiarch 제한 사항이 있나요? 디버그 패키지 생성?
제안, 지침, 힌트, 팁, 의견 및 기타 사항에 대해 감사드립니다.
현재 가장 좋은 추측은 git복제를 수행하지만(두 개의 프로세스/스레드를 볼 수 있음) QEMU_GDB사용 후 qemu에 의해 환경 변수가 설정 해제된다는 사실을 기반으로 합니다. 따라서 초기 프로세스만 gdb로 진행됩니다. 보다여기예를 들어.
하지만 그래도 상위 프로세스를 제대로 디버깅할 수 있어야 할까요? hello-world MWE를 쉽게 크로스 디버그할 수 있습니다.
답변1
"git clone"의 이 특별한 중단은 qemu 관련 문제인 것으로 밝혀졌습니다... qemu-user-emulation의 다른 문제가 우세하므로 전체 시스템 에뮬레이션으로 돌아가야 합니다... ;-(
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
그래서...
그런데 복잡한 프로그램은 아직도 역추적을 못해요...