Estou executando um wheezy: armhf chroot usando emulação do usuário qemu no meu sistema jessie: x86_64. De alguma forma, um git clone em um repositório privado em particular ficará suspenso dentro do chroot, enquanto é executado nativamente. Isso pode ser um bug, quem sabe? Para melhorar meu karma, quero descobrir o que está acontecendo!
Como uma nota: o travamento que estou experimentando está ocorrendo com git-2.0 dentro de jessie: armel chroot também ... O travamento não ocorre dentro de uma emulação de sistema completo. Então eu fui cavar o wheezy: armhf rabbithole, só porque eu tive que escolher um ... Eu não posso testar em uma máquina nativa ...
Não há git-dbg pacote, eu rolo o meu próprio. Dentro do 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
Até onde eu li, o gcc-documentation , definir DEB_CFLAGS_APPEND e DEB_CXXFLAGS_APPEND adicionalmente com -fno-stack-protector não é necessário, mas, de qualquer forma, queira ter certeza)
Depois, usando o gdb_stub do qemu dentro do chroot ' estou fazendo:
QEMU_GDB=1234 git clone /path/to/breaking/repo /tmp/bla
A depuração dentro do qemu gera um erro syscal 26 não suportado.
Ativando gdb-multiarch fora do chroot para conectar:
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?
Dar continue para permitir que o clone aconteça resultará em um travamento, o envio de um ctrl-c será ignorado.
Gerar um arquivo core e carregá-lo no gdb (dentro do chroot) me dará uma pilha corrompida:
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?)
Agora estou perdido.
Onde está o problema? Eu perdi alguns detalhes na emulação do usuário do qemu? Eu tenho que usar uma máquina de braço completamente emulada? Um mal-entendido na depuração cruzada? Limitações do gdb-multiarch? A criação de pacotes de depuração?
Obrigado por quaisquer sugestões, sugestões, sugestões, comentários e sugestões.
Meu melhor palpite no momento é baseado no fato de que git faz um clone (eu posso ver dois processos / threads), mas a variável de ambiente QEMU_GDB não é definida pelo qemu após o uso. Portanto, somente o processo inicial vai para o gdb. Consulte aqui , por exemplo.
Mas ainda assim: eu deveria ser capaz de depurar corretamente o processo pai? Posso depurar com facilidade um MWE de hello-world.