☰

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특정 개인 저장소의 a는 이 시스템에서 성공하는 동안 chroot 내부에 정지됩니다. 이것은 버그일지도 모릅니다. 누가 알겠습니까? 카르마를 개선하기 위해 무슨 일이 일어나고 있는지 알고 싶었습니다!

참고: 제가 겪은 정지 현상은 jessie:armel chroot 내부의 git-2.0에서도 발생했습니다... 전체 시스템 시뮬레이션에서는 정지 현상이 발생하지 않습니다. 그래서 계속 파고들고 있어요헐떡거림: 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 내에서 디버깅하면 다음이 발생합니다.지원되지 않는 시스템 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의 일부 세부정보를 놓쳤나요? 완전히 시뮬레이션된 암 머신을 사용해야 합니까? 크로스 디버깅 오해? gdb-multiarch 제한 사항이 있나요? 디버그 패키지를 만드시겠습니까?

제안, 지침, 팁, 힌트, 의견 등을 보내주셔서 감사합니다.

현재 가장 좋은 추측은 git복제가 수행된다는 사실을 기반으로 하지만(프로세스/스레드를 모두 볼 수 있음) QEMU_GDBqemu를 사용한 후에는 환경 변수가 설정되지 않았습니다. 따라서 초기 프로세스만 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

그래서...

하지만 복잡한 프로그램에 대해서는 여전히 추적을 얻을 수 없습니다...

관련 정보